-
-
Notifications
You must be signed in to change notification settings - Fork 30.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement PEP 394: The "python" Command on Unix-Like Systems #56836
Comments
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. |
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. |
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. |
Some scripts are installed by setup.py I’ll find time to read the latest version of the PEP in the coming days. |
The 2.7 patch needs to remove an existing python2 link before creating it. |
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. |
Actually, the Python 3 Makefile.pre.in is currently broken if Those are wrong, because the definition of Instead, they need to be written as "python$(VERSION)$(EXE)" and "python3$(EXE)" |
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. |
No automatic link, since I neglected to mention the issue number in the checkin messages: 2.7: http://hg.python.org/cpython/rev/a65a71aa9436 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. |
New changeset 499796937b7a by Ned Deily in branch '2.7': |
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. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: