[racket-dev] raco link

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 <mflatt at 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 <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93