A while ago I published Dreams of an ideal world: Package managers, where I expressed the idea that language package managers (eg. Pip, Cargo), should be used for language libraries rather than the OS package manager. A discussion I had on a mailing list prompted me to reconsider.
The person disagreeing with me described this as the "destructive philosophy brought to Linux by Pip people". They pointed out problems like the duplication of work between package managers and the inability to use all the features of the OS package manager for language libraries, and the separation of the dependency graph: while it's not common (since many modern languages statically link all their same-language dependencies by default), sometimes language packages depend on other things installed (for example, bindings to Qt), and when they're in completely separate systems managed by different tools, there's no easy way to express dependencies between them.
I still see at least two problems with using the OS package manager for language libraries:
They're very often out of date, and for obvious reasons: most maintainers of packages in high-level language ecosystems do not have commit access to distribution repositories, so they rely on distribution maintainers to update their versions - and we all know how unresponsive FOSS maintainers can be.
Each distribution with its own repositories has to have its own port of language libraries. This is somewhat the flipside of the duplication of work between package managers: it's either that, or duplication of work between package repositories. If I publish something on PyPI, it only has to exist there; the maintainers of FreeBSD, Debian, Arch, Fedora, and all the others don't have to know about it for their users to instantly get the latest version.
Ideally we discover/invent a system that allows high-level language packages to be ported to all operating systems without special attention from each OS's maintainers, while allowing dependency relationships between them. Thoughts?