There's a lot of overlap between programming language package managers and the OS one. A lot of time I could install something through pip or through pkg, and I've generally favored pkg in the past, but I'm having some different thoughts now.
There's a separation here. The OS package manager is for installing usable software; language-specific package managers are for installing libraries for that language. Of course, some projects like scapy blur this line, and I'm not sure which that belongs in. But I think I have a settled belief now: OS package managers should be used for general stuff and end-usable applications, while development libraries should be installed via the language's package manager.
Discussion (2)
It should be runtime-specific package managers, not language. Certain runtimes can run different languages. Often those runtimes are named after the first language they supported.
But back to your question. How do you expect usable software written in Python to be installed? The OS package manager should install the runtime package manager and install the packages via that?
What if those packages are not in a well maintained public repo?
I'd hate to see
apt install foo-bar-quuxfail because it's a NodeJS application and NPM has another "incident".I'm a little confused by that question. Runnable software written in Python (eg. Letsencrypt certbot) would obviously have to depend on installing Python.
As I said, I'm not sure about packages that are both end-usable and language libraries. It would have to install the interpreter/runtime for a language that needs one, but it might be a justification for putting it in the OS package repo, since it's something you might want to install for a reason other than using it to develop in that language.
I think it reduces the work that OS/distribution maintainers have to do if the OS package tool doesn't have to vendor so many language-specific libraries, and can just let the language's package manager handle it.