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
