Opened 10 years ago
Closed 10 years ago
#45130 closed enhancement (duplicate)
Follow recommendation on Python commands
Reported by: | anddam (Andrea D'Amore) | Owned by: | macports-dev@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.1 |
Keywords: | python | Cc: | |
Port: | python_select, python24, python25, python26, python27, python31, python32, python33, python34 |
Description
With respect to The "python" Command on Unix-Like Systems PEP I'm proposing a patch to follow the guidelines. It introduces python2 and python3 binaries in python ports' selection files.
The PEP suggests that for now python command point to the same target as python2.
This leads to an issue with current port selection feature: if python34 has a "-" value for the corresponding "$prefix/bin/python2" target in its select files entry it means that the "$prefix/bin/python2" symlink gets removed when the port is selected.
What we would like instead is that the "$prefix/bin/python2" would be left linking to an active python2X port, if there's any available, or should it rather be left at system's python executable?
There's a more complicated case in which ports python26 and python27 are both active and the system has to pick one. It could be handled by selecting the most recent version but again this is could be against user's specific needs.
Splitting the select groups in python2 and python3 wouldn't work well since there would be an overlap of the common entries. There's somehow need to mix the selections.
Any thought on this is welcome.
Attachments (1)
Change History (3)
Changed 10 years ago by anddam (Andrea D'Amore)
Attachment: | patch-python_pep394.diff added |
---|
comment:1 Changed 10 years ago by ned-deily (Ned Deily)
comment:2 Changed 10 years ago by larryv (Lawrence Velázquez)
Resolution: | → duplicate |
---|---|
Status: | new → closed |
There are already a bunch of tickets open on this topic. Let’s consolidate them into #34326.
"Splitting the select groups in python2 and python3 wouldn't work well since there would be an overlap of the common entries."
There shouldn't be any common entries between
python2
andpython3
installations and you could take this opportunity to fix that. I think the only overlap in current releases is the unversioned2to3
link and that could/should be resolved by deferring to thepython2
version. (2to3
is the same program for both py2 and py3, it's just a matter of which is the newest version.)