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