Bug 1265632 - System python (python2.6) is overloaded
System python (python2.6) is overloaded
Status: CLOSED NOTABUG
Product: softwarecollections.org
Classification: Community
Component: rh-python34 (Show other bugs)
1.0
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Python Maintainers
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-23 07:52 EDT by marianne@tuxette.fr
Modified: 2016-02-02 13:20 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-02 13:20:22 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description marianne@tuxette.fr 2015-09-23 07:52:32 EDT
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:
Comment 1 Honza Horak 2015-09-25 03:31:08 EDT
Well, this is how the SCL should work. What is the problem?
Comment 2 marianne@tuxette.fr 2015-09-25 03:43:50 EDT
No linux distribution has set python3 as default (except Archlinux) 
I was expecting the same behavior we have in Fedora
Comment 3 Matej Stuchlik 2015-09-25 05:40:29 EDT
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
Comment 4 Honza Horak 2015-09-25 10:28:01 EDT
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?
Comment 5 marianne@tuxette.fr 2015-09-25 11:02:28 EDT
Actually python and python3 in the SCL are symbolic links to python3.4 not binary
Comment 6 Robert Kuska 2015-09-29 04:45:24 EDT
Virtualenv behaves the same so I wouldn't consider changing this in SCL.
Comment 7 Matej Stuchlik 2015-09-29 05:22:49 EDT
(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@tuxette.fr from comment #5)
> Actually python and python3 in the SCL are symbolic links to python3.4 not
> binary

Right you are!
Comment 8 Petr Viktorin 2016-02-02 13:20:22 EST
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.

Note You need to log in before you can comment on or make changes to this bug.