Since Racket is a language promotes immutable state and data structure. Would it be nice to also have an immutable package system?
I propose a potential way of doing that. When a package is posting to the packages manage system. The system don’t overwrite the package but append a newer version of the package with a timestamp. Fetching package with a timestamp will only fetch the newest version before that timestamp.
I think the current system is merely shadowing the previous package, and garbage collection gets rid of the previous version :wink:
@laurent.orseau The garbage collection gets ride of the previous version while there are still references to it. The consequence is a mutable package system which breaks contracts all the time. :wink:
As a temporary fix, you can at least probably checkout a particular commit from github (if from there). Is this about one of your packages or someone else’s?
First, I want to suggest that proposals at the slack level of detail for major changes to the package system are not going to make a big difference
Second, one of the big challenges for many package system changes is that we don’t host the content of the packages, and don’t want to. So immutable package systems would have to address that somehow
It looks to me like the above is really just high level discussion and is by no means near a proposal, so Slack seems fine to me as a medium here. But feel free to tell us where to move the discussion to if you feel there’s a better way.
Otherwise, I (strangely) don’t have strong opinions here, but one thing that seems possible to me is for the package manager to collect the commit hashes of each git(hub) package at each new minor/major Racket version. Then raco could do something git --clone <pkg> && git --checkout <commit> . This would be very much like snapshots without hosting the packages themselves.
Another possibility is to greatly help the user generate versions of their packages and standardize the process. For example, one could imagine a raco command like raco github freeze [major] that would automatically generate the next minor (major) version git tag with a standardized numbering following Racket’s, and maybe even communicate with the pkgs server to generate a new package automatically.
Again, I’m not pushing for anything here, just thinking aloud.
I believe pkg server supports more than the git protocol, so the approach that deeply ties to git would be undesirable
Fair point, although offering better tools for the majority doesn’t mean letting down the rest—you can still do as before. Now I’m wondering what proportion of the packages on pkgs are non-git.
One important case is all the packages in “main-distribution” for all the releases are zip files.
Good point, although i would have excluded these from this tool.
Also imagine someone non-core develops such a useful tool (initially for his/her own purpose) that can be used by others without explicit support from pkgs, but works only for github. Would this be a bad thing?
> supports more than the git protocol Wouldn’t keep the original source reference and a timestamp work for most protocols?