This is great. I can't wait to experiment more with it. I noticed that the -r argument must be given the name of a directory and there doesn't seem to be an option to remove a collection by name. Once I realized that, I ran "raco link -r ../.." because that was where the original dir was. But this had an error:
% raco link -r ../.. path-element->string: expects argument of type <path>; given 'up === context === /Users/jay/Dev/scm/plt/collects/setup/link.rkt:85:5: for-loop /Users/jay/Dev/scm/plt/collects/setup/link.rkt:7:0: core17 /Users/jay/Dev/scm/plt/collects/setup/commands/link.rkt: [running body] /Users/jay/Dev/scm/plt/collects/raco/raco.rkt: [running body] /Users/jay/Dev/scm/plt/collects/raco/main.rkt: [running body] Jay On Wed, Aug 24, 2011 at 10:07 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > 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 > -- Jay McCarthy <j...@cs.byu.edu> Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
