I could see a case being made that programming language functions, especially in ruby where everything is message passing, forms a package manager. A method might actually want to guarantee that when it sends a message foo that the code receiving it remains fixed.
Being able to declare dependencies that granular might actually be great for doing refactors and upgrades. Maybe we accepted too easily that dependencies for a project are global.
Not really, it's not about downloading. If it only works offline given the appropriate files, that's fine too. But a package manager needs to actually install and uninstall packages!
>"The quacking that catches my ear is when something develops a dependency graph: your package depends on a package that depends on a package, and now you need resolution algorithms, lockfiles, integrity verification, and some way to answer “what am I actually running and how did it get here?”
Several tools that started as plugin systems, CI runners, and chart templating tools have quietly grown transitive dependency trees. Now they walk like a package manager, quack like a package manager, and have all the problems that npm and Cargo and Bundler have spent years learning to manage, though most of them haven’t caught up on the solutions."
On an aside, the MVS (minimum version selection) is an interesting and understandable algorithm for dependency resolution. Started from Go, CUE uses it now too.
It's wild to me that MVS didn't get picked up everywhere else for their next-gen package managers. Picking up "fixes" automatically turned out to be a boondoggle, if not a security risk. There's no reason we need to write a SAT solver just to manage our library dependencies.
> If it has transitive execution, it’s a package manager
Not really.
Spreadsheets, programming language functions, database triggers.
To be more accurate, if it downloads artifacts transitively it is a package manager.
I could see a case being made that programming language functions, especially in ruby where everything is message passing, forms a package manager. A method might actually want to guarantee that when it sends a message foo that the code receiving it remains fixed.
Being able to declare dependencies that granular might actually be great for doing refactors and upgrades. Maybe we accepted too easily that dependencies for a project are global.
in raku, versions are specified for imported packages, not for installed packages; you can specify in the code a dependency on a particular version
We sort of do by bundling them up and pinning them together at some version id.
Not really, it's not about downloading. If it only works offline given the appropriate files, that's fine too. But a package manager needs to actually install and uninstall packages!
>"The quacking that catches my ear is when something develops a dependency graph: your package depends on a package that depends on a package, and now you need resolution algorithms, lockfiles, integrity verification, and some way to answer “what am I actually running and how did it get here?”
Several tools that started as plugin systems, CI runners, and chart templating tools have quietly grown transitive dependency trees. Now they walk like a package manager, quack like a package manager, and have all the problems that npm and Cargo and Bundler have spent years learning to manage, though most of them haven’t caught up on the solutions."
https://edolstra.github.io/pubs/phd-thesis.pdf
On an aside, the MVS (minimum version selection) is an interesting and understandable algorithm for dependency resolution. Started from Go, CUE uses it now too.
https://research.swtch.com/vgo-mvs
It's wild to me that MVS didn't get picked up everywhere else for their next-gen package managers. Picking up "fixes" automatically turned out to be a boondoggle, if not a security risk. There's no reason we need to write a SAT solver just to manage our library dependencies.