[racket-dev] experiment reorganizing the repo into packages

At Wed, 29 May 2013 14:14:11 -0400, Eli Barzilay wrote:
> * Does this split actually work wrt having no circular dependencies?

It's mostly non-circular, but there are some exceptions.

I think there are no circularities among the "-lib" packages, but I'm
not 100% certain.

The existing "-docs" packages are probably all ultimately mutually
dependent. That's not all documentation, though, and there are still
some unresolved links; maybe we want to add more dependencies, or maybe
we want to use the experimental "indirect" options for section and
module-name references.

I should just write a program to draw the graph.

> * I usually like the fine split to packages like -docs and -lib.
>   However, minor subpoints:
> 
>   - Shouldn't the "-docs" suffix be "-doc" to be in-line with the
>     directory name and also symmetric to "-lib"?  (BTW, looking at the
>     Fedora installations that I have, there are both conventions, but
>     "-doc" is much more common than "-docs" , and "-libs" is a little
>     more common than "-lib".)

>   - I think that a -lib package is for cases where there is some use
>     for it by itself, and in some cases there's no need for that.
>     Things that I've seen:
>     - "xrepl-lib" -- there's no library functionality in xrepl that is
>       useful by itself, and if there is (or if something does become
>       useful), then it should move out of it.
>
>     - "at-exp-lib" -- the "lib" in the name seems confusing (because
>       there is no "at-exp", and I don't think that it's right to have
>       a "-lib"-only package...)
>     But I was confused:
> 
>   - Also, I'm looking at the "draw" package (and now that I see it,
>     "xrepl" too), and it looks like a hack that is compensating for
>     an inability to specify some "doc of" relation between packages.
>     (It's useful to have meta-packages, of course, it just looks like
>     the wrong level to specify such relationships.)  The fact that I
>     was confused about it seems to support this...
> 
>   - I'm also worried about the repo-implications of such splittage:
>     would there actually be three repositories for "foo", "foo-doc",
>     and "foo-lib"?  If so, then the price of not having in-package
>     specification for these things seem much higher; I will certainly
>     not want to see three such repos for xrepl...
> 
>   - There are also some "-lib" packages (like string-constants-lib)
>     that have no other forms.  (Especially in the string-constant
>     thing, having it be a -lib seems wrong to me.)
> 
>   - Similar issues are going to be relevant for other "package kinds"
>     like "-typed".  (The following sentence written after I've seen
>     much more:) So the more I see these things, the more I think that
>     it's bad to rely or encourage on this kind of post-pended suffix
>     as an indication of the package type -- I'd rather see these
>     things more formal and hopefully all distributable from within a
>     single per-real-package repository instead of an extra
>     meta-package for each.

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?


[You had *lots* of comments about specific packages --- which are
 certainly welcome, but let's tackle the big picture, first.]