Red Hat Bugzilla – Bug 1265632
System python (python2.6) is overloaded
Last modified: 2016-02-02 13:20:22 EST
Description of problem:
When enabling the scl, the default python is overloaded
Version-Release number of selected component (if applicable):
Install and enable the SCL
python is python3.4
python is python2.6 (system python)
python3 is python3.4
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. :)
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 email@example.com from comment #5)
> Actually python and python3 in the SCL are symbolic links to python3.4 not
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.