4 ms·
Awesome post! I worked with a bunch of package managers over the years and one can see that this design got inspired by the hood parts of a few I know. The onl
by larusso 3y ago
Awesome post! I worked with a bunch of package managers over the years and one can see that this design got inspired by the hood parts of a few I know.
The only design part I don‘t really like is the ‚latest‘ version specifier in the spec file. Which moves the declaration what the latest version is to the hosted location (in the example GitHub via GitHub API) paired with the fact that the checksums are also fetched rather than being part of the spec. This makes no sense for me. The spec needs to be versioned or better the spec is the actual location to declare a release. I kind of understand where the desire comes from to have a floating spec. Makes the publish process easier since one only creates a GitHub release in this case. But I would still argue that explicitly creating a new version of the spec for each version with baked checksums is better. The benefit for me would be that one could create a hash for each spec version for instance and use that internally for instance.
- friendzis 3y agoProbably the simplest version of a "package manager" are git submodules. Pointing submodule to `master` is effectively the same thing as pointing a "real" package manager to `latest`. This is trunk based development, however you implement it. One could easily argue that floating versions are considered harmful for releases outside of development team and should always be pinned, but on the other hand it is hard to argue against support for floating versions in development. As much as I dislike floating versions, I am not aware of any other way to force changes downstream.
- larusso 3y agoBrew has the —head flag where one can instruct to build the latest commit from the repo. But the spec/Formular needs to set a head to pull from.