[racket-dev] updated proposal for moving to packages

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 <samth at ccs.neu.edu> wrote:

> 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
> _________________________
>  Racket Developers list:
>  http://lists.racket-lang.org/dev