Description of problem: When enabling the scl, the default python is overloaded Version-Release number of selected component (if applicable): rh-python34-2.0-5.el6.x86_64 How reproducible: Install and enable the SCL Actual results: python is python3.4 Expected results: python is python2.6 (system python) python3 is python3.4 Additional info:
Well, this is how the SCL should work. What is the problem?
No linux distribution has set python3 as default (except Archlinux) I was expecting the same behavior we have in Fedora
As Honza noted, this is the expected behavior and AFAIK how most SCLs behave. That said, I agree that with Python it doesn't make quite as much sense, given the incompatibilities between Python 2 and 3 and the state in Fedora etc. I don't think we can do address this in the current RHSCL version without breaking things, but I'll definitely keep this in mind when planning the next version. Thanks for the report, Marianne. :) Matt
But what can be done with this? The only thing that got to my mind is not shipping 'python' binary in rh-python34 SCL and only ship 'python3' binary there.. is that what you meant, Matej? Or any other idea what to do?
Actually python and python3 in the SCL are symbolic links to python3.4 not binary
Virtualenv behaves the same so I wouldn't consider changing this in SCL.
(In reply to Honza Horak from comment #4) > But what can be done with this? The only thing that got to my mind is not > shipping 'python' binary in rh-python34 SCL and only ship 'python3' binary > there.. is that what you meant, Matej? Or any other idea what to do? Correct, that was my idea. Then again, as Robert noted, the current behavior is consistent with virtualenv's. I suppose it's a question of whether you think SCLs should behave more like virtualenv-like tools or more like the base distribution (In reply to marianne from comment #5) > Actually python and python3 in the SCL are symbolic links to python3.4 not > binary Right you are!
The behavior makes sense from SCL point of view (as Dan pointed out), and from the Python point of view (since it matches virtualenv). So I'm closing the bug. Thanks for the report though, Marianne! Don't let this discourage you from letting us know when things look broken.