[racket-dev] haskell's 'hell of a lot of libraries', planet

To add to what Dave said, quick brain dump, hopefully not too unreadable...

Most important for me, I'd like to be able to define multiple (what I'll 
call for now) repositories (like Debian "apt").  So that I can have, for 
example, a repository for core official blessed Racket components, one 
for contributed (what's currently PLaneT), and one for packages internal 
to an organization or project.  (Note that Debian has a mess of features 
for managing using multiple repositories, which most people don't know 
about, and which aren't necessarily reliable because not all tools 
respect the policy and some of the policy is kludgey anyway.)

Then, somehow I would like to prevent packages in the contributed 
repository from overriding those in the core and internal repositories.  
Guaranteeing this through naming, like Java packages, is one way, though 
that could be cumbersome.

It would be nice to be able to set policy in one place, for what 
packages and versions may be pulled from the non-internal repositories 
for a particular large system.  For example, since there are 
cost/benefit tradeoffs, to each third-party package we use, including 
security and quality, a project team might want to declare "this project 
may only use package foo version 1.3 and package bar versions 2.1-2.3 
from the contributed repository, and no others at this time".  (I have 
started to partly approximate this in one large system by having an 
intermediary "planet-*.ss" for each permitted require from PLaneT, but 
that alone does not prevent programmers from adding requires directly 
from PLaneT.)

Package signing to authenticate the packager still seems useful, like it 
did in the beginning, but that could be revisited in context of whatever 
other improvements are made.

When pulling from the contrib repository, we sometimes also need some 
confidence that version 1.3 today is the same code as when we vetted 
version 1.3 six months ago.  Maybe that's satisfied by us pulling from a 
transparent copy we made at the time (and not accidentally pulling from 
the repository).  Or maybe we copy the code and permanently disentangle 
it from PLaneT, which is expensive and stodgy.  Or maybe we trust the 
PLaneT server and our link to it not to be compromised, which we can for 
some applications but certainly not for all.  Or something else.

Separately, breaking up the monolithic Racket distribution into 
PLaneT-ish packages has some appeal to me, though it is not as important 
to me as the things above.  This appeal is partly pragmatic, such as an 
assumption that the factoring into modules will have a side effect of 
fitting Racket onto smaller storage, and the (rare, in my case) desire 
to pull some released improvement into a production system that is 
mostly frozen at an earlier Racket version.  The other part of appeal, 
at least to me, is aesthetic, in the same way that a self-hosting 
language implementation is considered elegant, and we might expect 
practical benefits to someday fall out of that (or perhaps they don't).  
If numerous PLaneT requests were actually used for the normal way of 
installing core, however, either all-at-once or on-demand, that could 
result in a poorer install-time or run-time experience than currently.  
So I think a monolithic tarball/zip/etc/dmg/etc would still be a good 
idea, even if internally it's broken up into packages.

If breaking up core into packages, and still offering a monolithic 
distribution tarball, whatever policy affordances the implementation of 
that monolithic packaging adds to PLaneT caches might also be applicable 
to purposes mentioned above, like selectively using a few contrib 
packages and being confident they don't change.

I'm guessing that most of this is relevant only to people doing large 
development, and who are engineering-inclined and looking to safe effort 
and stress.  However, one does not necessarily need these things to do 
large development successfully in Racket and using contributed PLaneT 
packages.

-- 
http://www.neilvandyke.org/