At Wed, 29 May 2013 15:51:30 -0400, Eli Barzilay wrote:
> 20 minutes ago, Matthew Flatt wrote:
> > > [..."package distribution kinds"...]
> >
> > Well, I agree with all these thoughts, but what's the conclusion?
> >
> > There's no requirement that packages be in multiple repositories,
> > but different packages in a single repository currently have to be
> > different subdirectories in the repository. Do we need (or do we
> > really want) a notion of "subpackages" to support some general form
> > of splitting within a package?
>
> I think so.
I've been trying to think through the details, and I don't see this as
the right direction for now.
You've sketched out the producer side, and I'm not sure of some about
some of those details. The consumer side seems even more complex to me.
It seems like the package system would have to keep track of which
subpackages are installed for a package, provide an interface to the
user (e.g., in the GUI) for subpackages, and be able to update a
package with new subpackages --- all while tracking dependencies at the
level of subpackages. I'm sure it can all be done, but I'm not sure how
difficult or important it will be relative to everything else that
still needs to be done, and I'm pretty sure it can't all be done right
now.
I'm inclined to think that the analogy to submodules is apt at the
level of the design process: we should try plain packages, first, and
when we understand them better try to improve with an extension to
subpackages.
Instead of trying to create subpackages, we might stick with a naming
convention. Even with a naming convention, it might make sense to
extend the package-manager GUI so that it recognizes the convention and
groups related packages together in a list view (but all the machinery
remains at the package level). Also, a package implementor is free to
develop "subpackages" along the lines you suggest, but splitting out
the subpackages into packages before handling them to a catalog.
Or, we could just not try to slice packages as finely for now, so that
the "-lib" and "-docs" packages of the experimental split are merged
together --- leaving a future split possibly to subpackages. That will
most likely result in a coarse layering that is close to "build-deps"
up to the "drracket" layer, but still provide more separation for
things that are outside the layer needed by DrRacket itself; for
example, "games", "redex", "htdp", "plai", "picturing-programs", and
"plot" can still be separate packages, I think.
To summarize, I see our options as
1. Suspend the effort to reorganize our repository into packages and
instead start experimenting with subpackages.
2. Use a naming convention and keep the same kind of split as in the
experimental reorganization --- and decide on some initial
conventions ("-lib", "-doc", "-typed", and "-exe"?).
3. Reorganize our repository into packages, but don't try to split out
things that conceptually belong together but have different kinds
of dependencies (such as run-time code versus documentation).
My preference in order is 2, 3, 1.
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
