<div dir="ltr"><div>That sounds all good to me! Thanks!<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 2, 2013 at 3:29 PM, Matthew Flatt <span dir="ltr"><<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[Jay will have to correct me if I have any part of this wrong...]<br> <div class="im"><br> At Thu, 2 May 2013 11:31:09 +0200, Laurent wrote:<br> </div><div class="im">> Say I want to use a package, registered on the PLaneT catalog as X.<br> > First I do `raco pkg install X`.<br> <br> </div>Yes.<br> <div class="im"><br> > In my Racket files, I simply use `(require X)'.<br> <br> </div>Assuming that package `X' supplies a collection `X', yes.<br> <br> Those don't have to be the same `X', although a package `X' will often<br> supply a collection `X' that has a "main.rkt" module. I point this out<br> to emphasize that modules refer to collection and library names --- not<br> to package names --- even though packages supply collections and<br> libraries.<br> <div class="im"><br> <br> > From time to time, the X devs implement a new feature, or fix some bugs,<br> > and my copy of X gets updated automatically (right?).<br> <br> </div>No. You only get an update when you explicitly run `raco pkg update' or<br> something equivalent (such as using DrRacket's GUI package manager).<br> <div class="im"><br> <br> > Now say that one of the X devs makes a mistake and commits a fatal bug,<br> > which will be seen and resolved only a week from now for whatever reason.<br> > My copy gets updated, and my Racket files relying on X don't work anymore.<br> > How can I ensure that my files still work as they were working yesterday,<br> > without needing interaction with the X devs?<br> <br> </div>Even with explicit updates, you might end up with a bad version.<br> <br> In that case, one option is to uninstall the package in install a<br> replacement through an explicit "package source", instead of using a<br> package name. That is, instead of<br> <br> raco pkg install X<br> <br> which uses a catalog to resolve `X', you could say something like<br> <br> raco pkg install X.tgz<br> <br> which just uses the given archive (which might have been downloaded as<br> a specific commit tarball form GitHub) as `X' with no interaction from<br> the catalog. A package installed this way is not subject to updating<br> via `raco pkg update'.<br> <br> <br> As an aside, the `raco pkg update' action is not restricted to packages<br> installed by package name; it also works with GutHub sources. If you<br> install via<br> <br> raco pkg install github://<a href="http://github.com/U/X/master" target="_blank">github.com/U/X/master</a><br> <br> then `raco pkg update' fetches the HEAD commit from GitHub. Again, that<br> install or update doesn't interact with the catalog. But it doesn't also<br> help if the repository's HEAD commit is buggy.<br> <br> <br> In general, you don't ever have to use a package name. (This is why<br> it's important that modules refer to collections and libraries, not<br> package names.) You can always work with a more direct specification of<br> a package implementation and ignore the catalog.<br> <div class="im"><br> <br> > If I understand properly, I need to create my own catalog that says that<br> > the package named X should not actually be looked up on PLaneT, but<br> > locally.<br> <br> </div>Yes, a catalog is one option for managing packages. It's a fairly<br> heavyweight option, though, that becomes convenient if you need to<br> manage many packages explicitly.<br> <div class="im"><br> > (Btw, is there a catalog hierarchy, so that if a package name is<br> > not found in one catalog, it can be checked in another, e.g., on PLaneT?)<br> <br> </div>Yes, `raco pkg' is configured with a sequence of catalogs, which it<br> tries in order.<br> <div class="im"><br> <br> > In this catalog, I associate the url with the last commit of X that worked<br> > with the package name X.<br> > Then I configure the new catalog, which probably updates my implementation<br> > of X, and thus rolls back to the working version.<br> <br> </div>Right --- you can do that with a catalog. It's simpler, though, to just<br> specify an implementation of the package directly, as above, during the<br> buggy period.<br> <div class="im"><br> <br> > A week later, the X devs apologize and tell me that a new version with a<br> > bug fix is released.<br> > Then I can remove my local catalog, reconfigure the package system so that<br> > it uses PLaneT instead of my local file, and normally my X implementation<br> > should be updated with the bug fix.<br> ><br> > Is this correct?<br> <br> </div>Yes, if you go the catalog route.<br> <br> If you installed from source instead of working with an extra catalog,<br> you can just uninstall the package and then re-install using the<br> package name instead of an explicit source. Doing so gets you the<br> current revision according to the catalog, and it makes the package a<br> candidate for `raco pkg update' again in the future.<br> <br> </blockquote></div><br></div>