31–40 of 106 posts
Earlier quoted context omitted.
Like silverblue with toolbox?
Something like Silverblue will only ever work with a rigid set in stone ROM-friendly base. You can't even do fixes with that, so Linux is right out. Lisp on bare metal, FORTH, anything. BASIC. It has to be small.
Although there is a mention for semver at the end:
> Decide what versioning scheme to use (Probably semver, or something like it/enhancing it with a total order).
I wonder if total order is appropriate (assuming the relation <= means compatibility), but it sure simplifies things. Basically throw away the major version, embed that in the name of the package if you have to.
Honestly pretty strange to write a package manager for sqlite and to use directories + json files to store the data instead of sqlite.
We have also been working hard recently on a package manager for configuring language KCL, which currently supports Git, OCI, and more.
It's surprisingly to me that no-one has built a asdf style package manager. (I'm not talking about system package managers, their language software packages are always out of date and get installed globally instead of locally to a project). Having a unified interface to a package manager per language that will use the languages registry could be really nice (I guess you'd have some core dependency management function…
(While creating some new ones.)
Why do we need a separate package manager for every programming language and every extensible library/app?
In theory we need only one for all, but in reality, that is impossible.
The author added a lockfile without understanding why they exist. A lockfile is meant to "freeze" dependency version resolution when package authors can specify dependencies on other packages using version ranges... it also "freezes" choices of transitive packages' versions when different packages depend on the same one, but with different versions. They chose to not handle package dependencies at all, and I believe…
A version number is just a label, and labels are mutable. A lock-file containing hashes will always resolve to the same packages (or fail).
Earlier quoted context omitted.
A version number is just a label, and labels are mutable. A lock-file containing hashes will always resolve to the same packages (or fail).
Depending on a single specific version is wrong. A library can be changed to fix a bug without changing the interface in any breaking way. It should be possible for a user (also their package manager, automatically) to replace the library with the new version in this case.