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, tho.)
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. Robby On Tue, May 28, 2013 at 4:14 PM, Matthew Flatt <mfl...@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 >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
