[bandrami]

I can't think of a single external packaging system that actually does Python non-painfully. Then again I can't think of an internal Python packaging system (there are like 5 now) that does Python non-painfully. But since one of the selling points of Nix is "it's like virtualenv but for everything", it's a little disappointing that it doesn't mesh better.

I'm not a Python developer, though I use applications that require Python libraries. I don't want a separate numpy for every application I use tucked away in my home folder somewhere; I want a system numpy provided by my distro that can't get out of sync because there's only one copy of it anywhere.

[mikepurvis]

I think the Debian model is okay, it just falls down in terms of being able to have any kind of meaningful cooperation between the debs and what pip does, and of course there's the massive velocity mismatch between what's on PyPI and what's in your distro.... and of course no way to install more than one instance of something so heaven help you if you have two down-tree packages that depend on a different version of a thing.

Okay yeah no, even Debian pretty much sucks.

[bandrami]

And this isn't new: it was true for gems with Ruby, it was true for pear with PHP, it was true for CPAN with perl. I don't do javascript at all but I assume it's doubly true for npm just because that place seems to make even pypi look conservative and glacial. I've mostly come around to the belief that if an piece of software has a package manager you should just use it instead of your system package manager. But man do I miss the days of CPAN packages that might update once a year.

[mikepurvis]

Generally I'm in agreement, but the one place that starts to fall apart is with bindings— if there's a native code library, then I really would prefer that library come in from the native package manager rather than be smuggled in by pip... but that's not generally how it works these days, and outside of Nix there isn't a great way to resolve this case.