[racket] Planet2 questions

[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.