Thanks for a pointer to the implementation! Trying things out --- and,
to a lesser degree, looking at the source --- answered a lot of my
initial questions.
While I was able to run `zcpkg serve`, I wasn't able to set things up
so that a request via `zcpkg -E ... install ...` downloaded from it. It
may be because I'm unclear on how configurations work. Can you provide
more hints on how to set that up?
I'm unclear whether I'm using/understanding cross-package imports
correctly. If I have a package "alpha" that depends on a package
"beta", where "a.rkt" in "alpha" uses "b.rkt" in "beta", and assuming
that "beta" is at "draft:0", it seems that right now I have to write
this in "a.rkt":
(require "../../../../mflatt/beta/draft/0/b.rkt")
Is that the intent?
I can imagine that the intent is instead to set up links so that
(require "../mflatt/beta/draft/b.rkt")
or maybe even
(require "../mflatt/beta/b.rkt")
would work. Meanwhile, dependency information for the "alpha" package
could specify "draft" and maybe even "draft:0".
[FWIW: Experience with PLaneT was that if you allow dependencies
without an edition, that shorthand will be used often, and then
breaking changes for a new edition turn out to be a problem after all.
But, if I guess right about the intent with `require`, a difference
was that PLaneT dependencies were always encoded in a `require`
reference instead of in separate package metadata.]
> I'm open to increasing interoperability with `raco pkg`, but I'm honestly
> unsure if that can be done easily. I know this isn't a PLT-sanctioned
> approach, but I'd like to know if there's any warmth to the direction I'm
> headed here.
As Matthias says, I'm skeptical of "PLT-sactioned". "Interesting to
people who know the current internals, and enough that they'd help make
sure it fits together" is a sensible question, though I can only answer
for myself.
I think this is an interesting direction.
Interoperability with `raco pkg` might mean that code could be used
either in `raco pkg` mode or `zcpkg` mode. If so, I can imagine a new
`require` subform that is
* treated like a "../" path when resolved relative to a filesystem
path (as it would appear in a `zcpkg` install), and
* treated like a collection-based path when resolved relative to a
collection-based path (as it would appear in a `raco pkg` install).
Things that manipulate modules paths for different purposes would all
have to change to deal with the new form, but I think it might work.
Crucially, your design avoids search paths, which cause all sorts of
trouble. In the implementation that I imagine, a `zcpkg`-installed
package would be able to see `raco pkg`-installed packages, but not
vice versa, which I think it what you have in mind.
But my guesses depend in part on whether I've understood the intended
way of referencing modules across `zcpkg` packages.
Matthew