[racket-dev] raco link

The latest version of Racket includes an experimental `raco link'
command for linking a collection name to a directory.

For example, suppose you work on three collections, "superweb",
"superglue", and "superdoc", and you have all three as directories
within a "super" git repo. Then, you'd set up your working space with

 git checkout ...super
 cd super
 raco link superweb superglue superdoc

Afterward,

 (require superglue/bind)

uses the "bind.rkt" module from "superglue" in your git checkout.


You could accomplish the same thing by setting the "PLTCOLLECTS"
environment variable, but `raco link' can be simpler for lots of
reasons. For example, if you have a DrRacket already running, then it
immediately sees the links installed by `raco link'.

The link created by `raco link' is user-specific by default. (It's not
version specific, but you can attach a regexp to a link to limit the
Racket versions for which it applies.) Use the `-i' flag to create an
installation-wide link.

You can have multiple links for the same collection, and the
corresponding directories are spliced together in the same way as for
(and along with) collection directories.

See also `setup/link'.


Toward A New Package System?
----------------------------

Packages will be based on collections, and I think `raco link' could
be a part of the workflow for developing a package. The package starts
out as a collection (or set of collections) on your machine, and `raco
link' lets you work on the package sources anywhere in your filesystem
without messing with PLTCOLLECTS or having to put all collections in
the same place. Creating a distribution for a package would work the
same for any set of collections. When a package is installed, maybe
the content goes into the installation or user-specific collection
directory, or maybe `raco link' is also useful for package
installation.

More immediately, we could experiment with moving collections out of
"collects" in the main Racket git repo, but not necessarily out of the
repo. For example, the "handin-server" collection might be moved from
"collects" to an "extras" directory that isn't included in the main
distribution. Someone who wants to use the handin server would clone
the git repo, cd to "extras", and run

  raco link -i handin-server
  raco setup

Then, the "handin-server" collection would work. Links persist across
git updates, so for the user who always wants the handin server,
"handin-server" works like any other collection in the distribution
--- just with the extra step of explicitly selecting it for any new
git checkout.


Other Uses and Approaches
-------------------------

The location of the user-specific collection links file can be
specified through a command-line argument to `racket'. So, it's
tempting to think of the links file as a kind of project
configuration. I don't now whether that's a good idea, but someone may
want to experiment with it.

A links file is a data file (which you can edit directly, if you
prefer), not a module. Normally, I'm opposed to data files that aren't
modules, but there's a bootstraping problem in this case: the links
file is supposed to control module-path resolution, so how would you
write a module that controls module-path resolution? In a setting
where a two-phase bootstrapping approach works, then we already have
the `current-module-name-resolver' parameter that you can set before
loading the rest of your program.