[racket-dev] experiment reorganizing the repo into packages

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Tue May 28 20:36:14 EDT 2013

This looks great to me!

I don't have a good sense of what level of granularity is the right one,
but I naturally would have gone even finer grained with drracket: the
macro-debugger, pkg/gui, and maybe even the gui-debugger I would have
separated out. (Probably you were focused on lower-level things first,

Also for the macro-debugger: I think it is useful by itself, without
drracket (I would like to use it for files that in drracket's
implementation, for example). So I think there should be two packages
there: macro-debugger-standalone with the "give me a file and show the
macro debugger's result on it" interface and macro-debugger-plugin pkg that
fits into drracket.


On Tue, May 28, 2013 at 4:14 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:

> Here's a first experiment at moving collections around into packages:
>  https://github.com/mflatt/racket/tree/pkg
> That repository really is meant as an experiment and a point of
> discussion --- not a conclusion!
> In particular, this experiment is about what it might look like to
> break up the Racket sources. It's about what the packages will actually
> be and how finely we want to layer the packages.
> To get the discussion started, I've tried to err on the side of
> breaking things apart (i.e., lots of layers). So, you'll see lots of
> packages.
> The "racket" directory in the repo is pretty much the same as the
> `min-racket' experiment, while each other directory is a package (or a
> sketch of a package, because I didn't get to everything, yet).
> If you build in the "racket" directory, install suitable native-library
> packages (see "README.txt") and then run
>  racket/bin/raco pkg install -i --link --deps link-auto drracket
> then you should get a Racket variant that includes DrRacket, but not
> the teaching languages, Redex, or lots of other things.
> If you instead try
>  racket/bin/raco pkg install -i --link --deps link-auto gui-lib
> then you should get a Racket that can run GUI programs, but no DrRacket
> or even documentation.
> As the "README.txt" notes, there are many useful packages that you can
> install and still keep things relatively small. For example, you can
> get a Scribble (without documentation!), Typed Racket, or a web server
> with relatively few dependencies.
> Meanwhile, part of this experiment is defining "-lib" packages that do
> not provide documentation, which means they can have fewer build-time
> dependencies than they would need for documentation. The "-docs"
> packages provide the corresponding documentation. (I'm not sure about
> the naming convention; I just had to pick something for now.)
> Naturally, the "X" package pulls in both the "X-lib" and "X-doc"
> packages.
> I don't know whether the "-lib"/"-docs" split is worthwhile, but it's
> part of erring on the side of breaking things apart. Maybe it makes
> more sense to keep things together and rely on binary packaging to
> reduce dependencies.
> Also worth noting is that the "unstable" collection does not work
> nicely as a package --- as should be expected. I created a few
> "unstable-" packages and imagine many more, but I'm not sure that's the
> right way to go.
> So, how does this split correspond to what you expected? (My guess is
> that this far too fine-grained for some of us, while others will want
> exactly this kind of flexibility.)
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130528/78b6f7c8/attachment.html>

Posted on the dev mailing list.