Did you try to organize the repository along the distribution specs with all documentation brought in at the very top?
I can imagine that anyone who downloads textual Racket wants to run it on a machine that is not where he develops the code. Indeed, the dev machine will have a full-fledged Racket tree with gui and all. If docs were on-line, we wouldh't have this problem either. Thanks for trying -- Matthias On Jun 13, 2013, at 5:44 PM, Sam Tobin-Hochstadt <sa...@ccs.neu.edu> wrote: > On Wed, Jun 5, 2013 at 8:19 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote: >> >> * The details of the repository organization (including where to split >> repositories) should be different. >> >> As described in next section of this message, the experimental >> repository represents a revised proposal, but there's plenty of room >> for further refinement. > > Matthew asked me to try a less fine-grained organization of packages. > My initial attempt at this is here: > https://github.com/samth/racket/tree/pkg > > However, I don't think this is an improvement (also, it doesn't fully > work). In particular, the dependency cliques are very large, and > basically obviate the usefulness of a lot of the splits. There are > some small packages, but basically everything depends on everything > else. For example, Typed Racket brings in all of the gui libraries, > all of the documentation, and the future visualizer. > > For me, this has been a useful exercise, and I now understand the > constraints somewhat better. I think we have, roughly, two options: > > 1. Something like the split Matthew's tree proposes. In fact, I think > we need to split some things further, so that `gui-lib` doesn't depend > on scribble-related things. > 2. Something much, much more coarse-grained, such as the current split > between the 'textual', 'graphical', 'drracket', and 'full' > distributions. Note that even these don't really make sense because of > documentation build dependencies. > > I think that 1 is the right choice. > > I also think that continuing to develop in separate branches as > proposals is a mistake. It's very hard to understand what's going on > in the `pkg` version of the tree without using it -- I certainly > didn't. it's also very hard to construct working trees in this fashion > without anyone using the code. If we're going to make this transition > soon, we should do it now, and then reorganize packages as necessary. > > Sam > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev _________________________ Racket Developers list: http://lists.racket-lang.org/dev
