My sibling makes a great point about type errors: did you know Cargo (Rust) only supports diamond dependencies where the versions differ only in major version[^0]? So you can have exactly the same problem with B depending on D@v1.1 and C depending on D@v1.2 in Cargo. I believe the reason for only supporting concurrent versions with different major versions (to use the paper's parlance) is because packages with different major versions should have incompatible APIs anyway.
[^0]: Or 0 major version and differing minor version -- Cargo has it's own definition of semver incompatible
> ... and it becomes a pseudo SAT problem in some cases if you want optimal dependency resolution
A couple of clarifications: many dependency resolution algorithms are essentially SAT even if they support concurrent versions (see Cargo). Section 3.3 of the paper might be an interesting read -- it discusses the spectrum of complexity in the problem of dependency resolution, and why some ecosystem's approaches don't work for others. Also, it's generally a 'pseudo SAT problem' (i.e. NP-complete and can be reduced to SAT) to find any valid resolution, not just an optimal one.
> This is the core algorithmic and architectural limit on package managers. Almost everything else is just implementation and engineering details.
I agree, and that's why the paper focuses on the semantics of dependency expression and dependency resolution! But there's a lot more than concurrent versions in the semantics of how package managers express and resolve dependencies, i.e. features, formula, peer dependencies. The point of the paper is that there's a minimal common core that we can use to translate between package management ecosystems, which we're planning on using to build useful tooling to bridge multilingual dependency resolution.
> So you can have exactly the same problem with B depending on D@v1.1 and C depending on D@v1.2 in Cargo. I believe the reason for only supporting concurrent versions with different major versions (to use the paper's parlance) is because packages should have incompatible APIs anyway.
Presumably you mean compatible rather than incompatible there?
The rust ecosystem standardised on semver. This means it is perfectly allowed to use 1.2 in place of 1.1. While you can specify upper bounds for the depdnency ranges, that is extremely uncommon in practice. Instead the bounds are just “1.1 or newer semver compatible" etc.
See https://semver.org/ for more on semver (but do note that Rust uses a variation, where it also applies to the leading non-zero component of 0.x).
How many of those are between a crate and it's proc macro crate? E.g. serde and serde_derive. I believe that is a common use case for exact dependencies, as they are really the same crate but have to be split due to how proc-macros work. But that is getting down in the weeds of peculiarites of how rustc works.
Very good points. Though to be pedantic, for package managers with concurrent/diamond dependencies support, there's nothing stopping you from pulling in every single dependency of every dependency (this is ~linear time with respect to the depth dependency tree, since you are not conducting any search here but just pulling them in at face value), and maybe deduplicating in linear/constant time with a Set data structure. In this case it's it's very obviously not a SAT problem, but it's ridiculously inefficient since there's zero optimization on the dependency tree. The moment you apply optimizations on it to turn it into a graph from a tree and prune it gets closer to, yes, a SAT problem.
The MirageOS project [0] is a great collection of functionality pure OCaml libraries that are useful outside of unikernels. I've used the DNS library with an effectful layer for various nameserver experiments [1].
Author of Eon here, there's still some open questions I have here about managing the lifetimes of these certificates. Renewal is supported via a Capnproto callback and there's some ad-hoc integration in with NixOS nginx to restart it on a certificate renewal. https://github.com/RyanGibb/eon/blob/3a3f5bae2b308b677edfb3f...
This doesn't work in the general case, e.g. for postfix and dovecot, and is only becoming more pertinent with short lived certificates. It would be great if the service manager could use these capabilities directly. I think GNU Shepard's integration with Guile Goblins and OCapN is a step in the right direction here: https://spritely.institute/news/spritely-nlnet-grants-decemb...
This is a good argument for the Unix philosophy's "do one thing" to avoid the bloat the author describes. E.g. vi, sendmail, and some bash for Word's mail merge. Or Emacs and some lisp. But then the onus is on the user to compose these tools to something that solves their particular problem.
99% hardship of any advanced tool that is expected to be used by any random person is in integration, discoverability, fault tolerance, pragmatic relevant guidance.
I love Vim (RIP Bram, thanks for all the fish), but it's a tool for the less than 1% who loves that kind of thing.
Most people won't learn the tool because they see it only as an anecdotal detail bringing hindrance in their quest to "something".
reply