In the real world...if you have a large fleet of RHEL5 boxes/VM's, this a fact of life. We're slowly phasing out our CentOS 5 boxes, but you still need to be able to run new software on them.
>not the sort of system you push new software to.
Telling customers that they are doing things wrong isn't really a great way to win customers.
This is something I don't understand. If someone is using Java, they'll install the version of Java they need. If they use Ruby, they'll install the version of Ruby they need. If they need Lua, they'll do the same thing.
Why everyone is relying on python that's installed there for RedHat's needs (e.g. yum).
Unlike other languages, Python is probably the best one that can have multiple versions coexist together.
As a consultant I have very different experiences. Even in Java development you find shops that refuse to upgrade their JVM for various reasons.
RHEL 5 is really common.
Re:From Python to Lua: Why We Switched
by ghshephard on Wednesday January 27, 2016 @09:22AM
(#10980087)
A lot (all that I'm familiar with) of the enterprise software packages that I've worked with ship with their own, very specific (read: regression tested against) version of java. Enterprise software usually requires a ton of servers, so it's not like anything else on those servers will be using the jvm.
> Why everyone is relying on python that's installed there for RedHat's needs
Environments where the build of your server is strictly controlled and conservative...banks, mission critical apps, that kinda thing where stability from upstream is hugely important.
Re:From Python to Lua: Why We Switched
by voltagex_ on Wednesday January 27, 2016 @01:11AM
(#10978532)
AFAICT if you want support from Red Hat, you better not mess with the system configuration. It's probably best not to mess with too much on your production boxes anyway (maybe that's why Docker is so popular)
How about running a (newer) local version of Python, without of course touching the system Python?
To my mind, it's usually a good idea not to use system Python, both packages and the interpreter, if you're not also controlling them. This makes building your deployables more involved, but makes the actual deployment more painless.
I still use a few RHEL5 machines but nobody would ever dream of pushing new software to them.