3 ms·
He doesn't blame it on 'some boneheaded decision'. As far as I can see, he doesn't blame anyone, he just notes the current state of affairs, in which the situat
by Confusion 16y ago
He doesn't blame it on 'some boneheaded decision'. As far as I can see, he doesn't blame anyone, he just notes the current state of affairs, in which the situation is indeed pretty much broken. Not just for him, because he is far from the only one that thinks it should work a certain way.
that's why virtualenv was invented
Yes and shouldn't it also be the OSes that use it to isolate their default Python install?
- rbanffy 16y agoIt's a design decision. They have a default Python install they support, validate and keep working that you shouldn't mess with. I am pretty sure you can't ruin a RHEL just by installing RPMs from RH's repos. If the Python the OS vendor provides is somewhat inadequate to you, it's your job to provide another one or to use another distro. However, if you choose to write your code against the distro's Python (something that's not that hard, really - 2.4 is a modern language) you can rest assured your code will work for as long as the distro is supported. It's not "broken", not a boneheaded decision. It's just the way it is. If you require 2.7 or 3.x goodness, you can always set-up different environments separate from the OS's Python and just be happy with it. And, BTW, I never put boneheaded in quotes ;-)
- sophacles 16y agoIt is completely possible, easy and reasonable to have a multiple versions of python installed. Many OSes do this, and the convention is to have them named like python2.4 python2.5 and so on. Any system scripts that require 2.4 can then change their shebang to say /usr/bin/python2.4. At the very same time, packages for newer pythons can be made available for ease-of-use for the rest of the world. This breaks nothing.