The tools installed by pip won't usually work with the old versions of Python found by default on some systems. They break because they want a new Python feature, and that makes you want to upgrade and that... you can't do that because it will break dependencies at system level.
And then you want to install a new Python side by side and you sort of do that but /usr/bin/python still points to the old version and you have to be explicit with /usr/bin/python2.6 in your scripts. But then some scripts will work and some still don't and you make /usr/bin/python point to /usr/bin/python2.6 and now you really broke yum.
And all you can do now is hate python because it gave you all these problems.
As a sysadmin, I hated java way more than python :-)
At least, with java, no one even attempts to use distro package tools to manage libraries, packages and dependencies. Can you see a sysadmin using a syslog replacement implemented in java, requiring java8, along with a webserver only running on java5?
With python, some tools (those big enough to be packaged) are no problem. Some random tool from pip -- not so much -- now you have to patch that python binary, those python dependencies etc... and not just track security.your-distro.org.
It is certainly possible to deploy your system in a similar way you deploy your apps (take on 100% of the burden of maintaining the whole thing) -- but normally you want the "system" to be a stable foundation on which to erect your rickety duct-taped mono-jvm-python-ruby app-stack with the help of puppet/chef/cfengine/salt/ansible... you don't want pip/hackage/gem/npm to manage your system. You might trust it to manage a single application.
It should be very easy. Things are never installed system-wide -- no cross-app conflicts. When starting an application, either you manually specify each file or directory to include, or you just package every dependency into your executable jar file.
This system administrator hates Java almost as much as Windows. I'm still enraged at the old lie "compile once, run everywhere". Just look at what Java does to the Red Hat "alternatives" system, although I can't imagine any prettier body cast around that catastrophe.
Reading your comment the irony occurs to me that the best solution to "compile once" has been real VMs. Not Java VMs, but full god damned fucking virtual machines running the OS and environment you determine should run in them.
You've still got to provision those, but, well, they're individual and isolated and tend not to go hammering into one another. Other than consuming all available system resources.
Oddly: IBM got this right with VM ... 40 years ago?
Comments
The tools installed by pip won't usually work with the old versions of Python found by default on some systems. They break because they want a new Python feature, and that makes you want to upgrade and that... you can't do that because it will break dependencies at system level.
And then you want to install a new Python side by side and you sort of do that but /usr/bin/python still points to the old version and you have to be explicit with /usr/bin/python2.6 in your scripts. But then some scripts will work and some still don't and you make /usr/bin/python point to /usr/bin/python2.6 and now you really broke yum.
And all you can do now is hate python because it gave you all these problems.
And I can't imagine what it is like to deploy Java apps if you have no actual familiarity with the JVM ecosystem, either.
As a sysadmin, I hated java way more than python :-)
At least, with java, no one even attempts to use distro package tools to manage libraries, packages and dependencies. Can you see a sysadmin using a syslog replacement implemented in java, requiring java8, along with a webserver only running on java5?
With python, some tools (those big enough to be packaged) are no problem. Some random tool from pip -- not so much -- now you have to patch that python binary, those python dependencies etc... and not just track security.your-distro.org.
It is certainly possible to deploy your system in a similar way you deploy your apps (take on 100% of the burden of maintaining the whole thing) -- but normally you want the "system" to be a stable foundation on which to erect your rickety duct-taped mono-jvm-python-ruby app-stack with the help of puppet/chef/cfengine/salt/ansible... you don't want pip/hackage/gem/npm to manage your system. You might trust it to manage a single application.
It should be very easy. Things are never installed system-wide -- no cross-app conflicts. When starting an application, either you manually specify each file or directory to include, or you just package every dependency into your executable jar file.
What is your point? That administrators really hate Java too?
This system administrator hates Java almost as much as Windows. I'm still enraged at the old lie "compile once, run everywhere". Just look at what Java does to the Red Hat "alternatives" system, although I can't imagine any prettier body cast around that catastrophe.
Reading your comment the irony occurs to me that the best solution to "compile once" has been real VMs. Not Java VMs, but full god damned fucking virtual machines running the OS and environment you determine should run in them.
You've still got to provision those, but, well, they're individual and isolated and tend not to go hammering into one another. Other than consuming all available system resources.
Oddly: IBM got this right with VM ... 40 years ago?
https://en.wikipedia.org/wiki/VM_(operating_system)