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.
