3 ms·
Nix allows two packages to exist simultaneously on the filesystem and can even put both in your $LANGPATH (i.e., PYTHONPATH, CLASSPATH, GOPATH, etc), but the li
by weberc2 10y ago
Nix allows two packages to exist simultaneously on the filesystem and can even put both in your $LANGPATH (i.e., PYTHONPATH, CLASSPATH, GOPATH, etc), but the linker/runtime will still only look at the first package to resolve correctly, ignoring the second. In other words, Nix just sets up your environment--the language tools still have the final say about how they resolve multiple dependencies within that environment.
- chriswarbo 10y agoI suppose one thing to keep in mind is the interface that the packaged software provides. If packages A and B provide standalone binaries /bin/A and /bin/B, and package C depends on both, then the dependencies of A and B are pretty much isolated: each can use their own versions of whatever they like, and C can invoke both binaries.* On the other hand, if A and B provide (some sort of) libraries which C imports, then their dependencies may be exposed by appearing in the pool of libraries available to C. This is certainly the case for Haskell, where all of a library's dependencies accumulate in the ghc-pkg database and multiple versions of a library aren't allowed in the same program. As you say, such things are existing problems in external, language-specific tools, and aren't caused by Nix; although Nix may provide a useful abstraction to better manage such problems. * There may be application-specific problems at runtime, e.g. if A and B try to de/serialise each other's data, but I'd count that as a bug: if A and B are meant to be standalone then they're buggy, as their I/O formats should be more robust; on the other hand, if A and B are meant to be used together then the packaging is buggy: A and B should expose their shared dependency as a parameter, and C should pass in the same version to both.