à la Carte, the formal way is contingent on whether intermediate representation of dependencies, are "enable[d] as translation between distinct package managers."
I will make it simpler to understand. There is only one thing that make or breaks package resolution: do you support diamond dependencies and when.
A diamond dependency is when you have package A depending on package B and C. B depends on package D@v1 while C depends on D@v2. V1 and V2 are incompatible versions of D. This is a classic dependency conflict problem and whether you can resolve it automatically and bundle both packages into the final codebase/binary is the most important architectural decision of the package manager.
Package managers/ecosystems that support diamond dependencies in most circumstances:
Npm (as long as it's not a peer dep), Golang, Rust, Java/.NET (with shading enabled, it's not turned on by default).
With diamond dependency support, in most circumstances you can have arbitrary depth /complexity of dependency resolution.
If you don't support diamond dependencies (basically the rest of the world, Python, Ruby, Dart, Elixir, most lisps in their default setup, statically linked C/C++ in default configurations, maybe Zig too, I am not sure about that one), your dependency tree size is severely limited and it becomes a pseudo SAT problem in some cases if you want optimal dependency resolution.
This is the core algorithmic and architectural limit on package managers. Almost everything else is just implementation and engineering details. Stuff like centralized vs non centralized repos, package caching proxies, security hashes, chains of trust, vendoring, SLSA/SBOM etc. can all be bolted on as an after thought but supporting conflicting upstream dependencies simultaneously requires compliance on the bundler/transpiler/compiler level.
It's also why some languages lend themselves better to tools like Bazel that micromanages every single dependency you have while others do not.
The paper does make this distinction under the "Concurrent Versions" property.
Allowing concurrent versions though opens you up to either really insidious runtime bugs or impossible-to-solve static type errors.
This happens eg. when you receive a package.SomeType@v1, and then try to call some other package with it that expects a package.SomeType@v2. At that point you get undefined runtime behavior (JavaScript), or a static type error that can only be solved by allowing you to import two versions of the same package at the same time (and this gets real complicated real fast).
Also, global state (if there is any) will be duplicated for the same package, which generally also leads to very hard-to-discover bugs and undefined behavior.
Geo-tagging even deviations on Street Maps.
à la Carte, the formal way is contingent on whether intermediate representation of dependencies, are "enable[d] as translation between distinct package managers."
I will make it simpler to understand. There is only one thing that make or breaks package resolution: do you support diamond dependencies and when.
A diamond dependency is when you have package A depending on package B and C. B depends on package D@v1 while C depends on D@v2. V1 and V2 are incompatible versions of D. This is a classic dependency conflict problem and whether you can resolve it automatically and bundle both packages into the final codebase/binary is the most important architectural decision of the package manager.
Package managers/ecosystems that support diamond dependencies in most circumstances:
Npm (as long as it's not a peer dep), Golang, Rust, Java/.NET (with shading enabled, it's not turned on by default).
With diamond dependency support, in most circumstances you can have arbitrary depth /complexity of dependency resolution.
If you don't support diamond dependencies (basically the rest of the world, Python, Ruby, Dart, Elixir, most lisps in their default setup, statically linked C/C++ in default configurations, maybe Zig too, I am not sure about that one), your dependency tree size is severely limited and it becomes a pseudo SAT problem in some cases if you want optimal dependency resolution.
This is the core algorithmic and architectural limit on package managers. Almost everything else is just implementation and engineering details. Stuff like centralized vs non centralized repos, package caching proxies, security hashes, chains of trust, vendoring, SLSA/SBOM etc. can all be bolted on as an after thought but supporting conflicting upstream dependencies simultaneously requires compliance on the bundler/transpiler/compiler level.
It's also why some languages lend themselves better to tools like Bazel that micromanages every single dependency you have while others do not.
The paper does make this distinction under the "Concurrent Versions" property.
Allowing concurrent versions though opens you up to either really insidious runtime bugs or impossible-to-solve static type errors.
This happens eg. when you receive a package.SomeType@v1, and then try to call some other package with it that expects a package.SomeType@v2. At that point you get undefined runtime behavior (JavaScript), or a static type error that can only be solved by allowing you to import two versions of the same package at the same time (and this gets real complicated real fast).
Also, global state (if there is any) will be duplicated for the same package, which generally also leads to very hard-to-discover bugs and undefined behavior.
Good points. Practically speaking though global state is rarely an issue unless it's the underlying framework (hence peer deps).
Modern languages are mostly lexically scoped and global variables have fallen out of favor outside of embedded unless it's a one off script.