Apologies for the "PLT-sanctioned" comment. I came off differently than intended.
> 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. Your attempt would have worked. The server just isn't done. I didn't emphasize it much in the README, but I ended up taking a detour to work from minimal Racket. That led to building the service from the transport layer. While I deal with that, I'm afraid the only way to preview functionality now is by installing local directories. > I'm unclear whether I'm using/understanding cross-package imports correctly. A conventional "zcpkg-deps" directory is made available in installed packages as defined in https://github.com/zyrolasting/zcpkg/blob/master/file.rkt#L114 You're looking for something like: (require (file "zcpkg-deps/example.com/package/module.rkt")). I wouldn't want to ask someone to navigate a directory structure outside of their package boundary. Obviously a require transformer would be nice, but at the level I'm targeting I have the chicken-and-egg problem re: where that binding comes from. For now, this is the added verbosity I mentioned. Currently I assume that a dependent package only needs one version of a package, which is why the path above does not include version information. I haven't yet decided if this should change. > Interoperability with `raco pkg` might mean that code could be used > either in `raco pkg` mode or `zcpkg` mode. I visualized the project as adding casework: Racket packages define at least one collection, so what changes with a zero-collection package? Well, everything, so it felt more like `raco pkg` having an "advanced" mode. It seemed wise to keep my code isolated while I figured things out. After reading Sam Boyer's article, it might be better to say that zcpkg is a PDM and raco pkg is an LDM. If `raco pkg` could operate such that PDM, LDM, and SDM were treated as modes, I suppose that would work just as well. It would certainly give a minimal Racket installation more powers over userspace, but I imagine the CLI would be fiendishly complicated. ~slg ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Saturday, July 25, 2020 9:37 PM, Matthew Flatt <[email protected]> wrote: > At Sat, 25 Jul 2020 21:36:20 +0000, Sage Gerard wrote: > > > The source is at https://github.com/zyrolasting/zcpkg. > > 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 > > -- > You received this message because you are subscribed to the Google Groups > "Racket Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-dev/20200725193756.13a%40sirmail.smtp.cs.utah.edu. > -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/2_g2eh_6wkeVCtQNPOYEoStGCiqrF1NaNKc7er8RkbZjxx1rISyhQOWXO_Ei9bq6cRuZYUGoLIFzCPdM-oFj-BXiNgnNUHB5gU_3g46kywE%3D%40sagegerard.com.
