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 racket-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/20200725193756.13a%40sirmail.smtp.cs.utah.edu.
