Repository navigation
Implement PEP 394: The "python" Command on Unix-Like Systems #56836
Description
| BPO | 12627 |
|---|---|
| Nosy | @loewis, @ncoghlan, @benjaminp, @ned-deily, @merwok, @meadori, @akheron |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/ned-deily'
closed_at = <Date 2012-02-19.02:03:17.678>
created_at = <Date 2011-07-24.02:31:35.040>
labels = ['type-feature', 'expert-installation']
title = 'Implement PEP 394: The "python" Command on Unix-Like Systems'
updated_at = <Date 2012-02-19.02:03:17.676>
user = 'https://bugs.python.org/KerrickStaley'bugs.python.org fields:
activity = <Date 2012-02-19.02:03:17.676>
actor = 'ned.deily'
assignee = 'ned.deily'
closed = True
closed_date = <Date 2012-02-19.02:03:17.678>
closer = 'ned.deily'
components = ['Installation']
creation = <Date 2011-07-24.02:31:35.040>
creator = 'Kerrick.Staley'
dependencies = []
files = ['24530']
hgrepos = []
issue_num = 12627
keywords = ['patch']
message_count = 11.0
messages = ['141034', '141035', '141036', '141046', '153303', '153477', '153478', '153479', '153543', '153664', '153665']
nosy_count = 10.0
nosy_names = ['loewis', 'ncoghlan', 'benjamin.peterson', 'ned.deily', 'eric.araujo', 'meador.inge', 'python-dev', 'petri.lehtinen', 'Kerrick.Staley', 'jbicha']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue12627'
versions = ['Python 2.7', 'Python 3.3']
Activity
KerrickStaley commentedon Jul 24, 2011
This issue was opened to track the implementation of PEP-394, which governs the way the python command and commands like python2 and python3 work on Unix-like systems.
KerrickStaley commentedon Jul 24, 2011
Here is a patch that will update the Makefile.pre.in file for 2.7, causing it to install python2 and python2-config when run with "make install" (or just "make bininstall"). This does not update any documentation. Also, it appears that Idle and PyDoc are not installed by the 2.7 Makefile, so I didn't do anything about those, even though the PEP mentions them.
KerrickStaley commentedon Jul 24, 2011
This updates the links created by "make install" or "make bininstall" in Python 3 so that they're in agreement with the recommendations of PEP-394; it's the equivalent of version27_links.patch but is for Python 3.
merwok commentedon Jul 24, 2011
Some scripts are installed by setup.py
I’ll find time to read the latest version of the PEP in the coming days.
loewis commentedon Feb 13, 2012
The 2.7 patch needs to remove an existing python2 link before creating it.
ncoghlan commentedon Feb 16, 2012
I removed the 3.3 patch, since all the previous version did was change symbolic links to hard links, and the latest round of discussions favoured retaining the symlinks since they're much easier to introspect.
However, it turns out there is still one change needed for 3.3 - updating the current python3 hardlink to make it a symlink instead.
ncoghlan commentedon Feb 16, 2012
Actually, the Python 3 Makefile.pre.in is currently broken if$(EXE) is ever non-empty - in a few places it uses "$ (PYTHON)$(VERSION)$(EXE)" and "$(PYTHON)3$(EXE)".
Those are wrong, because the definition of$(PYTHON) at the top of the file is "python$ (EXE)"
Instead, they need to be written as "python$(VERSION)$(EXE)" and "python3$(EXE)"
ncoghlan commentedon Feb 16, 2012
New patch that aims to create the appropriate symlinks in "make bininstall". I don't currently have a sacrificial VM set up to test it in though.
ncoghlan commentedon Feb 17, 2012
No automatic link, since I neglected to mention the issue number in the checkin messages:
2.7: http://hg.python.org/cpython/rev/a65a71aa9436
3.3: http://hg.python.org/cpython/rev/dc721f28f168
I deliberately *didn't* make the change in 3.2. As the choice of symlink vs hardlink is really more cosmetic than consequential, it didn't feel like an appropriate change to make in a maintenance release without a compelling reason (introducing a *new* link meant we had such a reason for 2.7, but that's not applicable to 3.2).
Handing the issue over to Ned to confirm the OS X framework builds align with the PEP.
python-dev commentedon Feb 19, 2012
New changeset 499796937b7a by Ned Deily in branch '2.7':
Issue bpo-12627: Implement PEP-394 for OS X framework builds.
http://hg.python.org/cpython/rev/499796937b7a
ned-deily commentedon Feb 19, 2012
Changeset 499796937b7a implements PEP-394 for OS X framework builds on Python 2.7. OS X framework builds already created versioned symlinks for all executables and scripts installed in the framework bin directory, of the general form ${cmd} - ${cmd}2.7. This is all accomplished in some additional targets in Mac/Makefile which are automatically added by configure for framework builds and supersede the standard processing in the main Makefile bininstall and altbininstall targets. The changes here add the additional hierarchy of ${cmd} -> ${cmd}2 -> ${cmd}2.7. Per previous practice, all of the links are created in the framework bin directory for both the install and altinstall targets. This is consistent with the long-standing recommendation to manage multiple framework versions by adding and ordering framework bin directories on $PATH. Also, per past practice, symlinks to all framework bin entries are created in $prefix/bin (by default, /usr/local/bin) for the install target and only versioned links are created for altinstall, although the use of these links is not recommended for framework builds and their installation is optional with the standard OS X installers.
No changes are needed for 3.2 or 3.3 at this time. Although the Mac/Makefile targets don't quite create all of the versioned links in $prefix/bin, the installer build script does the right thing by creating symlinks to everything in the fw bin directory.
In many respects, the current situation for framework builds is less than ideal, with duplicated code, vestigial links, and, more importantly, a clumsy and non-transparent method for managing multiple versions. I intend to revisit this area prior to Python 3.3 feature code cutoff as a separate issue.