3 ms·
Never thought of dependencies as a SAT issue before... Makes sense once I think about it. I always imagined dependencies as a tree. If I have dependency x whi
by Gunax 3y ago
Never thought of dependencies as a SAT issue before... Makes sense once I think about it.
I always imagined dependencies as a tree.
If I have dependency x which uses foo 1.0 and dependency y which uses foo 2.0, isn't it possible to get an unsatisfiable rule?
Why do we need a universal version of foo? Cant we just use both foo 1.0 and 2.0? When being used by x, we use foo1.0 and when being used by y, use foo 2.0
- duped 3y agoDependencies are a graph, not a tree. Say z depends on x and y, which version of foo do you use? Requiring a single version makes certain things a lot easier to deal with, because not all dependencies are actually inherited by another. If foo is an executable then sure, you can have multiple versions and it's no issue. If foo is a library then you might need to fail because there is no solution that works. Or you might not, it depends.
- droelf 3y agoNPM actually works like this afaik (you can have multiple versions of a given package in tree). Vendoring is another way to work around the single-version per name requirement. It's mainly problematic with shared types and when they "escape" over the API boundary (ie. are exposed somehow).
- karatinversion 3y ago> Why do we need a universal version of foo? Cant we just use both foo 1.0 and 2.0? When being used by x, we use foo1.0 and when being used by y, use foo 2.0 You need language-level support for your packaging for this, so that the compiler or runtime can bind a call to foo.bar() to foo 1.0 when the call happens in x, and foo 2.0 when it happens in y.
- wofo 3y agoAuthor here. As others have commented, some package managers allow multiple versions of the same dependency. Conda doesn't, and I wanted to stick to the Conda rules in the article ;)