| I use Nix to manage python environments, and it’s quite revealing. For instance, a few months ago I was working on an environment for playing around with some libraries that you’d think would commonly go together. But within the community there are very popular libraries that cannot be used together (at recent enough commits to contain features I want) due to version conflicts. But as I’m a nix person I obviously try to solve that by going rogue. This was my process before I decided to pack it in and wait for the community to sort their shit out: 1. Pull projects at their latest commit instead. This is the “hope the communities already have their shit sorted out” method. nope, no luck. 2. Write a patch that changes the older requirement. Maybe it is API compatible? LOL no such luck. 3. Write a patch that changes the outdated dependency name to some random name, then add an expression to map the outdated dependency to that name instead. Ugh no, there are version incompatibility with its own dependencies too. 4. Write a patch to update the lib with the outdated dependency to use the new API instead - success! On its own. Now use it together with the other libraries… uh oh. It has a C++ backend that requires a GLIBC version that is incompatible with that used by the other libraries. It needs this because it needs to be built with a specific CUDA-enabled compiler that is quite outdated now, and if you compile it on a newer version it fails to build because the author hardcoded the compatibility matrix into the codebase with c macros. So yeah there comes a point where you think “hey I want to try out using some fun tools I’ve heard about” and, before you know it, you’re writing a patch for a dependency that allows you to use a patched version of another dependency that allows you to use a patched version of a dependency that you want to add to your project alongside something else, and at some point you’ve just got to quit and hope that in a few weeks there will be version parity. |
Poetry, pipenv, etc are all about building dependency tree solvers into python package management.. so if you have package a that depends on package c >= 2.0 and package b that depends on package c < 2.5, you will get package c installed in version 2.5…
Nix basically says “Python packages are lying when they say they need this specific package version. Ignore that and install whatever version is in nixpkgs”.
Which sucks! There are some badly maintained workarounds (poetry2nix and pip2nix come to mind… neither of which works for m1 macs), but the whole stance is just wrong.