[racket-dev] updated proposal for moving to packages

From: Sam Tobin-Hochstadt (samth at ccs.neu.edu)
Date: Thu Jun 13 17:44:17 EDT 2013

On Wed, Jun 5, 2013 at 8:19 PM, Matthew Flatt <mflatt at 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

Posted on the dev mailing list.