Reviving this thread. I spent the last couple of months on a package manager 
that operates at a broader scope than `raco pkg`. It's not done because as you 
all know, package managers are hard.

The source is at https://github.com/zyrolasting/zcpkg. Note that there's a 
branch dedicated to using only minimal Racket, and I'll be leaning on that once 
I learn how to properly set up TCP+TLS.

In the context of this thread, there's a point where a Racket developer depends 
less on Racket packages and more on specific Racket installations. The name 
`zcpkg` stands for "Zero-Collection Packages", since it explores extending 
Racket where packages don't modify the running installation. Obviously this 
entails more verbose specifications and require specs.

After some reading I found that my goals overlapped with Nix and Guix. In this 
light, all I'm really doing is moving the boundary for the "unit of exchange" 
(Sam Boyer's works [1]) to encompass a Racket installation and non-Racket 
resources. My hope is that will address the topic discussed in this thread, 
since you can install a Racket package that includes the means by which Racket 
runs to support that package.

It also acts as a nice use case for reader extensions, since it does not seem 
like a huge leap from my current state to adapt setup/infotab to what Guile and 
Nix's language are doing. Jury is still out... I could be embarrassingly wrong.

The HN thread for Boyer's article is also pretty valuable since it has people 
articulating pain points, and that's coloring my approach. [2]

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.

[1]: 
https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527#.740o43vxi
[2]: https://news.ycombinator.com/item?id=11088125


~slg

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, May 21, 2020 11:50 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote:

> At Thu, 21 May 2020 15:39:30 +0000, Sage Gerard wrote:
>
> > I'm not sure what improvements can be made that A) wouldn't repeat the
> > problems encountered in PLaneT and B) gives users an "easy" way to deal with
> > breaking changes in collection names beyond what the Package Management FAQ
> > suggests.
>
> Well, I hope you take my comments in the spirit of "advice that may be
> wrong". When multiple things change between A and B, saying which
> changes mattered ends up being a matter of opinion and interpretation.
>
> > I remember Sam mentioning `raco link` in Slack, but based on your
> > emails it sounds like NOTHING can fundamentally change without a
> > tethered installation or custom distribution (e.g. a collects-like
> > directory relative to a different executable). Is that correct? I
> > wasn't sure if you were hinting at that in your first email.
>
> You can do many things with just environment variables (e.g., to pick a
> configuration directory). A tethered environment solves the problem
> that environment variables are too widely scoped; if your Racket
> program is meant to start a separate process that runs a different
> Racket, for example, the environment variables affects the second
> Racket --- unless the original program goes out of its way to remove
> them.
>
> > If that's the case, then I'd probably double down on my first reply:
> > It almost seems like giving users an easy way to generate tethered
> > installations would open up more opportunities than trying to make
> > the default installation behave a certain way around packages,
> > collections, and modules.
>
> I still agree with this.
>
> ---------------------------
>
> 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/20200521095040.19d%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 racket-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-dev/omt_978Tt0WX5ZFWVca240MWk4yz4-4cpGVYVkzc1mKL9LF55s3qIhelqsXkQys5DnWZo0X7Hx_lNqAfHI6nAuEPhO5RmKcAdOR6FYAanqY%3D%40sagegerard.com.

Reply via email to