"pip handles that too!" One is not supposed to have more than one software management subsystem on a server because it leads to a hodge-podge mess: imagine you

"pip handles that too!" One is not supposed to have more than one software management subsystem on a server because it leads to a hodge-podge mess: imagine you have 100'000 servers and it's RPM this, then pip that, then pear other, then npm whatever, then cargo something else... it would become a system administration nightmare in 0.1, and a system engineering nightmare in 0.01 seconds... you have to troubleshoot production, and do, what? Start firing different private packaging format commands in the hopes you find the correct one to find out what's been done to the system, what's available, then pray that particular private packaging system supports some sort of verification feature in order to find out who hacked which file with what tool? And that's okay by you? It certainly isn't okay by me and would have never worked in an environment that large (it doesn't even work in very small environments!) ...One is always supposed to use the native software management system of the operating system: cattle, not pets. And if there isn't a native OS package of the software one needs, or there isn't one of sufficient quality and standards compliance (like LSB FHS), then one makes one's own packages, because that is the high quality, professional way of doing things.