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. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
