5 ms·
There is no real theory because it's a solved problem--packages and dependencies form a DAG or graph and it's just an ordering and traversal problem that's easi
by qbasic_forever 4y ago
There is no real theory because it's a solved problem--packages and dependencies form a DAG or graph and it's just an ordering and traversal problem that's easily solved.
The pain and fragmentation you're mentioning is that everyone has different opinions about how they want to configure/bundle/organize code and package metadata. That's really the only core difference between deb/rpm, npm/yarn, pip/poetry/conda/<a million other python tools>, handmade makefile/cmake/autotools/etc. People just had different ideas about how they wanted to do things at the periphery. At their core all of those tools are just simple DAG walkers.
Basically, you're thinking it's a technical problem when in reality it's just a social issue. Some people prefer something one way, others prefer it the other way--there is no consensus (and likely never will be, people will always be building tools to do things their way).
- jmull 4y agoWell, not DAG, because the A is for acyclic, and dependency graphs can definitely contain cycles.
- pxc 4y agoYeah, that's a misfeature. It should definitely be a DAG. Which ecosystems 'support' that besides Node?
- lamontcg 4y agoThey really shouldn't, and some dependency systems like rubygems/bundler after the molinillo switch ban them entirely.
- tremon 4y agoIn the case of immutable builds (and hence immutable dependencies), dependency graphs cannot contain cycles. At most they can have the same package occur twice in the graph, but with different dependencies or different build options.
- jmull 4y agoYou might be referring to something specific thing I'm not familiar with... generally, an immutable build doesn't impose a structure on your dependency graph, just that it can't change (in any detail, hopefully) from build to build, without an explicit change in source.