[racket-dev] experiment reorganizing the repo into packages

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.)