Thanks for all the replies. The main sources of inflexibility seem to be:
- Python has a global module space
- nixpkgs python packages do not correctly model that python runtime requirements frequently don’t need to be there at build time.
- mach-nix does not recurse into nixpkgs dependencies or explicitly represent their dependency graph in the dependency resolution
We could of course already hack our way around it, by just taking the original nixpkgs package and patching it, like we patch binaries from pypi or conda.
Is this required? It seems by merging the pypi and nixpkgs dependency graphs, it should be possible to avoid modifying anything in nixpkgs, only adding packages from pypi.
I’d be happy to contribute here if it doesn’t sound too hard.
If I ever manage to finalize the conda support and get it into the stable version, this would probably already solve the problem kind of, since conda provides many more binary releases than pypi.
I agree. Conda packages are often cleaner too, since they won’t bundle e.g. libgfortran in numpy. BTW, mach-nix’s dependency resolution is about 100000 times faster than condas.