[racket-dev] PLaneT(2): Single vs multi-collection packages
At Mon, 3 Jun 2013 18:37:43 +0200, Laurent wrote:
> Here is a patch for a proof of concept (file /collects/pkg/lib.rkt).
>
> The modifications are minimal as I had expected, but obviously I only have
> a very narrow view of the package system, so probably something does not
> work properly.
> In particular, I changed only for the 'dir type, and did not touch the
> 'link type.
> Since the 'github type and others use the 'dir type once the archive is
> downloaded, I think it should work as expected for those too.
Thanks --- I appreciate your willingness to contribute!
Speaking for myself, I'd like to see a full implementation rather than
a proof of concept. In this case, I've implemented the idea once
before, and so I know it's basically possible. But I didn't like how
the details worked out in my approach, so I'm hoping that someone will
find a better approach to the details. Unfortunately, that really
requires getting into all the details.
I'll echo Jay's observation that this patch's implementation leaves a
single-collection package's installation without an "info.rkt" file,
which is needed for information like package-level dependencies.
The simplification of not handling links also seems like a big weakness
to me. I think one of the best things about Jay's design is that I
don't have to change the way I think about a package when moving
between link and non-link modes (which makes it much easier to work
with a GitHub repository, for example). I particularly encourage you to
think about what should happen when a user needs to transition a GitHub
repo from a representing a single-collection package to a
multiple-collection package --- and how that interacts with links as
well as non-link, GitHub-based installations of the package.
Meanwhile, as we've started leaning on the package system and looked at
how to fit our current collections into it, I think we're running into
the same problem at another level: if "web-server-lib" and
"web-server-doc" are both packages in a single "web-server" repository,
and if they have to be separate directories, then we have yet another
layer of directories that affect repository layout. Maybe there's a
more general answer to the directory-layout problem that would neatly
cover single-collection packages.