PEP 394 request for pronouncement (python2 symlink in *nix systems)
PEP 394 [1] aims to document our collective recommendation for allowing shebang lines to specifically request some version of 2.x, without requiring that it be exactly 2.7 (or 2.6, etc). I'd let this drift for a while, but the imminent release of 2.7.3 makes it necessary to push for a final pronouncement. Kerrick has the necessary Makefile.pre.in patch up on the tracker [2] to add the hard link for the python2 name. We could, of course, make the recommendation to distributions without updating "make install" and "make bininstall" to follow our own advice, but that seems needlessly inconsistent. [1] http://www.python.org/dev/peps/pep-0394/ [2] http://bugs.python.org/issue12627 Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sun, 12 Feb 2012 19:04:30 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
PEP 394 [1] aims to document our collective recommendation for allowing shebang lines to specifically request some version of 2.x, without requiring that it be exactly 2.7 (or 2.6, etc).
I'd let this drift for a while, but the imminent release of 2.7.3 makes it necessary to push for a final pronouncement. Kerrick has the necessary Makefile.pre.in patch up on the tracker [2] to add the hard link for the python2 name.
Why hard links? Symlinks are much more introspectable. When looking at a hard link I have no easy way to know it's the same as whatever other file in the same directory. I also don't understand this mention: “The make install command in the CPython 3.x series will similarly install the python3.x, idle3.x, pydoc3.x, and python3.x-config binaries (with appropriate x), and python3, idle3, pydoc3, and python3-config as hard links. This feature will first appear in CPython 3.3.” This feature actually exists in 3.2 (but with a symlink, fortunately): $ ls -la ~/opt/bin/pydoc3 lrwxrwxrwx 1 antoine antoine 8 oct. 15 21:24 /home/antoine/opt/bin/pydoc3 -> pydoc3.2* Regards Antoine.
Why hard links? Symlinks are much more introspectable. When looking at a hard link I have no easy way to know it's the same as whatever other file in the same directory.
There actually *is* an easy way, in regular ls: look at the link count. It comes out of ls -l by default, and if it's >1, there will be an identical file. I agree with the question, though: this needs to be justified (but there may well be a justification).
I also don't understand this mention:
“The make install command in the CPython 3.x series will similarly install the python3.x, idle3.x, pydoc3.x, and python3.x-config binaries (with appropriate x), and python3, idle3, pydoc3, and python3-config as hard links. This feature will first appear in CPython 3.3.”
This feature actually exists in 3.2 (but with a symlink, fortunately):
If you look at the patch, you'll notice that the only change is to make the links hard links. Regards, Martin
Le dimanche 12 février 2012 à 16:52 +0100, "Martin v. Löwis" a écrit :
Why hard links? Symlinks are much more introspectable. When looking at a hard link I have no easy way to know it's the same as whatever other file in the same directory.
There actually *is* an easy way, in regular ls: look at the link count. It comes out of ls -l by default, and if it's >1, there will be an identical file.
This doesn't tell me which file it is, which is practically useless if I have both python3.3 and python3.2 in that directory.
If you look at the patch, you'll notice that the only change is to make the links hard links.
This begs the question: why? Regards Antoine.
There actually *is* an easy way, in regular ls: look at the link count. It comes out of ls -l by default, and if it's >1, there will be an identical file.
This doesn't tell me which file it is, which is practically useless if I have both python3.3 and python3.2 in that directory.
You can use 'ls -i' to print the inode, or you could use find's 'samefile' option. But this is definitely not as straightforward as a it would be for a symlink, and I'm also curious to know the reason behind this choice.
Am 12.02.2012 17:04, schrieb Antoine Pitrou:
Le dimanche 12 février 2012 à 16:52 +0100, "Martin v. Löwis" a écrit :
Why hard links? Symlinks are much more introspectable. When looking at a hard link I have no easy way to know it's the same as whatever other file in the same directory.
There actually *is* an easy way, in regular ls: look at the link count. It comes out of ls -l by default, and if it's >1, there will be an identical file.
This doesn't tell me which file it is
Well, you didn't ask for that, it does "to know it's the same as whatever other file" nicely :-) As Charles-François explains, you can use ls -i for that, which isn't that easy, but still straight-forward. Regards, Martin
On 12Feb2012 18:57, "Martin v. Löwis" <martin@v.loewis.de> wrote: | Am 12.02.2012 17:04, schrieb Antoine Pitrou: | > Le dimanche 12 février 2012 à 16:52 +0100, "Martin v. Löwis" a écrit : | >>> Why hard links? Symlinks are much more introspectable. When looking at | >>> a hard link I have no easy way to know it's the same as whatever other | >>> file in the same directory. | >> | >> There actually *is* an easy way, in regular ls: look at the link count. | >> It comes out of ls -l by default, and if it's >1, there will be an | >> identical file. Yeah! Somewhere... :-( | > This doesn't tell me which file it is | | Well, you didn't ask for that, it does "to know it's the same as | whatever other file" nicely :-) Sure, at the OS level. Not much use for _inspection_. | As Charles-François explains, you can use ls -i for that, which isn't | that easy, but still straight-forward. If the hardlink is nearby. Of course in this example it (almost certainly?) is, but it needn't be. A symlink is a much better solution to this problem because: - usability - "ls -l" shows it to the user by default - practicality: With a symlink, to find out what it attaches to you examine the symlink. With a hardlink you first examine a fairly opaque numeric attribute of "python2", and _then_ you examine every other filename on the system! Admittedly starting with "python2.*" in the same directory, but in principle in other places. Arbitrary other places. IMO a symlink is far and away the better choice in this situation. Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ I need your clothes, your boots, and your motorcycle. - Arnold Schwarzenegger, Terminator 2
On Mon, Feb 13, 2012 at 6:42 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
IMO a symlink is far and away the better choice in this situation.
Please wait with that judgment until you see the rationale of the PEP author.
Kerrick did post a rationale in the last thread [1], but it never made it into the PEP itself. The relevant comment: ========== Also, I updated the PEP with the clarification that commands like python3 should be hard links (because they'll be invoked from code and are more efficient; also, hard links are just as flexible as symlinks here), while commands like python should be soft links (because this makes it clear to sysadmins that they can be "switched", and it's needed for flexibility if python3 changes). This really doesn't matter, but can we keep it this way unless there are serious objections? ========== I think Antoine makes a good point about ease of introspection when you have multiple versions in the same series installed, so I'd be fine with: - updating the PEP recommendation to say that either form of link is fine (with hard links marginally faster, but harder to introspect) - noting that python.org releases will consistently use symlinks for easier introspection via "ls -l" - updating Makefile.pre.in to ensure that we really do consistently use symlinks This does mean that launching Python may involve a slightly longer symlink chain in some cases (python -> python2 -> python2.7), but the impact of that is always going to be utterly dwarfed by other startup costs. [1] http://mail.python.org/pipermail/python-dev/2011-July/112322.html Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I think Antoine makes a good point about ease of introspection when you have multiple versions in the same series installed, so I'd be fine with: - updating the PEP recommendation to say that either form of link is fine (with hard links marginally faster, but harder to introspect) - noting that python.org releases will consistently use symlinks for easier introspection via "ls -l" - updating Makefile.pre.in to ensure that we really do consistently use symlinks
Sounds fine to me as well. When you update the PEP, please also update the <TBD> mark with the actual issue number (or add it to the References). For the patch, it seems that one open issue is OSX support, although I'm unsure what exactly the issue is. Regards, Martin
On Tue, Feb 14, 2012 at 7:07 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I think Antoine makes a good point about ease of introspection when you have multiple versions in the same series installed, so I'd be fine with: - updating the PEP recommendation to say that either form of link is fine (with hard links marginally faster, but harder to introspect) - noting that python.org releases will consistently use symlinks for easier introspection via "ls -l" - updating Makefile.pre.in to ensure that we really do consistently use symlinks
Sounds fine to me as well. When you update the PEP, please also update the <TBD> mark with the actual issue number (or add it to the References).
Hmm, the PEP builder on python.org may need a kick. I added the tracker reference before starting this thread (http://hg.python.org/peps/rev/78b94f8648fa), but didn't comment on it since I expected the site to update in fairly short order.
For the patch, it seems that one open issue is OSX support, although I'm unsure what exactly the issue is.
I don't know either, but I'll take Ned's word for it if he says there's something more he needs to do to make it work in the OS X binaries. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Feb 13, 2012, at 12:31 PM, Nick Coghlan wrote:
I think Antoine makes a good point about ease of introspection when you have multiple versions in the same series installed, so I'd be fine with: - updating the PEP recommendation to say that either form of link is fine (with hard links marginally faster, but harder to introspect) - noting that python.org releases will consistently use symlinks for easier introspection via "ls -l" - updating Makefile.pre.in to ensure that we really do consistently use symlinks
+1, and +1 for the PEP to be accepted.
This does mean that launching Python may involve a slightly longer symlink chain in some cases (python -> python2 -> python2.7), but the impact of that is always going to be utterly dwarfed by other startup costs.
Agreed about startup times. However, does the symlink chain have to go in this order? Couldn't python -> python2.7 and python2 -> python2.7? OTOH, I seriously doubt removing one level of symlink chasing will have any noticeable effect on startup times. One other thing I'd like to see the PEP address is a possible migration strategy to python->python3. Even if that strategy is "don't do it, man!". IOW, can a distribution change the 'python' symlink once it's pointed to python2? What is the criteria for that? Is it up to a distribution? Will the PEP get updated when our collective wisdom says its time to change the default? etc. Also, if Python 2.7 is being changed to add this feature, why can't Python 3.2 also be changed? (And if there's a good reason for not doing it there, that should be added to the PEP.) Cheers, -Barry
On Tue, Feb 14, 2012 at 8:08 AM, Barry Warsaw <barry@python.org> wrote:
On Feb 13, 2012, at 12:31 PM, Nick Coghlan wrote:
I think Antoine makes a good point about ease of introspection when you have multiple versions in the same series installed, so I'd be fine with: - updating the PEP recommendation to say that either form of link is fine (with hard links marginally faster, but harder to introspect) - noting that python.org releases will consistently use symlinks for easier introspection via "ls -l" - updating Makefile.pre.in to ensure that we really do consistently use symlinks
+1, and +1 for the PEP to be accepted.
This does mean that launching Python may involve a slightly longer symlink chain in some cases (python -> python2 -> python2.7), but the impact of that is always going to be utterly dwarfed by other startup costs.
Agreed about startup times. However, does the symlink chain have to go in this order? Couldn't python -> python2.7 and python2 -> python2.7? OTOH, I seriously doubt removing one level of symlink chasing will have any noticeable effect on startup times.
I considered that, but thought it would be odd to make people double-key a manual default version change within a series. It seemed more logical to have "python" as a binary "python2/3" switch and then have the python2/3 symlinks choose which version is the default for that series. (I'll add that rationale to the PEP, though)
One other thing I'd like to see the PEP address is a possible migration strategy to python->python3. Even if that strategy is "don't do it, man!". IOW, can a distribution change the 'python' symlink once it's pointed to python2? What is the criteria for that? Is it up to a distribution? Will the PEP get updated when our collective wisdom says its time to change the default? etc.
I have no idea, and I'm not going to open that can of worms for this PEP. We need to say something about the executable aliases so that people can eventually write cross-platform python2 shebang lines, but how particular distros actually manage the transition is going to depend more on their infrastructure and community than it is anything to do with us.
Also, if Python 2.7 is being changed to add this feature, why can't Python 3.2 also be changed? (And if there's a good reason for not doing it there, that should be added to the PEP.)
Because Python 3.2 already installs itself as python3 and doesn't touch the python symlink. Aside from potentially cleaning up the choice of symlinks vs hardlinks in a couple of cases, the PEP really doesn't alter Python 3 deployment at all. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Feb 14, 2012, at 12:38 PM, Nick Coghlan wrote:
One other thing I'd like to see the PEP address is a possible migration strategy to python->python3. Even if that strategy is "don't do it, man!". IOW, can a distribution change the 'python' symlink once it's pointed to python2? What is the criteria for that? Is it up to a distribution? Will the PEP get updated when our collective wisdom says its time to change the default? etc.
I have no idea, and I'm not going to open that can of worms for this PEP. We need to say something about the executable aliases so that people can eventually write cross-platform python2 shebang lines, but how particular distros actually manage the transition is going to depend more on their infrastructure and community than it is anything to do with us.
Then I think all the PEP needs to say is that it is explicitly up to the distros to determine if, when, where, and how they transition. I.e. take it off of python-dev's plate. Cheers, -Barry
On Wed, Feb 15, 2012 at 12:44 AM, Barry Warsaw <barry@python.org> wrote:
On Feb 14, 2012, at 12:38 PM, Nick Coghlan wrote:
One other thing I'd like to see the PEP address is a possible migration strategy to python->python3. Even if that strategy is "don't do it, man!". IOW, can a distribution change the 'python' symlink once it's pointed to python2? What is the criteria for that? Is it up to a distribution? Will the PEP get updated when our collective wisdom says its time to change the default? etc.
I have no idea, and I'm not going to open that can of worms for this PEP. We need to say something about the executable aliases so that people can eventually write cross-platform python2 shebang lines, but how particular distros actually manage the transition is going to depend more on their infrastructure and community than it is anything to do with us.
Then I think all the PEP needs to say is that it is explicitly up to the distros to determine if, when, where, and how they transition. I.e. take it off of python-dev's plate.
Yeah, good idea. I'll also add an explicit link to the announcement of the Arch Linux transition [1] that precipitated this PEP. [1] https://www.archlinux.org/news/python-is-now-python-3/ -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Does this need a pronouncement? Worrying about the speed of symlinks seems silly, and exactly how the links are created (hard or soft, chaining or direct) should be up to the distro; our own Makefile should create chaining symlinks just so the mechanism is clear. -- --Guido van Rossum (python.org/~guido)
On Feb 15, 2012, at 09:20 AM, Guido van Rossum wrote:
Does this need a pronouncement? Worrying about the speed of symlinks seems silly, and exactly how the links are created (hard or soft, chaining or direct) should be up to the distro; our own Makefile should create chaining symlinks just so the mechanism is clear.
Works for me. -Barry
Guido van Rossum <guido@python.org> wrote:
Does this need a pronouncement? Worrying about the speed of symlinks seems silly
I agree. I wonder if a hard-link was used for legacy reasons. Some very old versions of Unix didn't have symlinks. It looks like it was introduced in BSD 4.2, released in 1983. That seems a long time before the birth of Python but perhaps some SysV systems were around that didn't have it. Also, maybe speed was more of a concern at that time. In any case, those days are long, long gone. Neil
+1 for using symlinks where possible. In deploying Python to different operating systems and filesystems I've often had to run a script to "fix" the hardlinking done by make install because the deployment mechanism or system couldn't be trusted to do the right thing with respect to minimising installation size. Symlinks are total win when disk use is a concern, and make intent clear. I'm not aware of any mainstream systems that don't support them.
On Wed, Feb 15, 2012 at 5:26 PM, Neil Schemenauer <nas@arctrix.com> wrote:
Guido van Rossum <guido@python.org> wrote:
Does this need a pronouncement? Worrying about the speed of symlinks seems silly
I agree. I wonder if a hard-link was used for legacy reasons. Some very old versions of Unix didn't have symlinks. It looks like it was introduced in BSD 4.2, released in 1983. That seems a long time before the birth of Python but perhaps some SysV systems were around that didn't have it. Also, maybe speed was more of a concern at that time. In any case, those days are long, long gone.
Actually I remember what was my motivation at the time (somewhere between 1995-1999 I think) that I decided to use a hard link. It was some trick whereby if you ran "make install" the target binary, e.g. "python1.3", was removed and then overwritten in such a way that code which was running it via "python" (a hard link to python1.3) would not be disturbed. Then a new hard link would be created atomically. But it was too clever, and it's long been replaced with a symlink. Anyway, I don't think anyone is objecting against the PEP allowing symlinks now. -- --Guido van Rossum (python.org/~guido)
On Thu, Feb 16, 2012 at 12:06 PM, Guido van Rossum <guido@python.org> wrote:
Anyway, I don't think anyone is objecting against the PEP allowing symlinks now.
Yeah, the onus is just back on me to do the final updates to the PEP and patch based on the discussion in this thread. Unless life unexpectedly intervenes, I expect that to happen on Saturday (my time). After that, the only further work is for Ned to supply whatever updates he needs to bring the 2.7 Mac OS X installers into line with the new naming scheme. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
In article <CADiSq7fg3Vgxd39teuvbCvhhmPKUwSS0qckSrfPKN5yE0dv3NQ@mail.gmail.com>, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Thu, Feb 16, 2012 at 12:06 PM, Guido van Rossum <guido@python.org> wrote:
Anyway, I don't think anyone is objecting against the PEP allowing symlinks now.
Yeah, the onus is just back on me to do the final updates to the PEP and patch based on the discussion in this thread. Unless life unexpectedly intervenes, I expect that to happen on Saturday (my time).
After that, the only further work is for Ned to supply whatever updates he needs to bring the 2.7 Mac OS X installers into line with the new naming scheme.
There are two issues that I know of for OS X. One is just getting a python2 symlink into the bin directory of a framework build. That's easy. The other is managing symlinks (python, python2, and python3) across framework bin directories; currently there's no infrastructure for that. That part will probably have to wait until PyCon. -- Ned Deily, nad@acm.org
There are two issues that I know of for OS X. One is just getting a python2 symlink into the bin directory of a framework build. That's easy.
Where exactly in the Makefile is that reflected? ISTM that the current patch already covers that, since the framwork* targets are not concerned with the bin directory.
The other is managing symlinks (python, python2, and python3) across framework bin directories; currently there's no infrastructure for that. That part will probably have to wait until PyCon.
What is the "framework bin directory"? The links are proposed for /usr/local/bin resp. /usr/bin. The proposed patch already manages these links across releases (the most recent install wins). If you are concerned about multiple feature releases: this is not an issue, since the links are just proposed for Python 2.7 (distributions may also add them for 2.6 and earlier, but we are not going to make a release in that direction). It may be that the PEP becomes irrelevant before it is widely accepted: if the sole remaining Python 2 version is 2.7, users may just as well refer to python2 as python2.7. Regards, Martin
On Thu, Feb 16, 2012 at 8:01 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
It may be that the PEP becomes irrelevant before it is widely accepted: if the sole remaining Python 2 version is 2.7, users may just as well refer to python2 as python2.7.
My hope is that a clear signal from us supporting a python2 symlink for cross-distro compatibility will encourage the commercial distros to add such a link to their 2.6 based variants (e.g. anything with an explicit python2.7 reference won't run by default on RHEL6, or rebuilds based on that). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I'm away from the source for the next 36 hours. I'll reply with patches by Saturday morning. ___ Ned Deily nad@acm.org -- [] ..... Original Message ....... On Thu, 16 Feb 2012 11:01:39 +0100 ""Martin v. Löwis"" <martin@v.loewis.de> wrote:
There are two issues that I know of for OS X. One is just getting a python2 symlink into the bin directory of a framework build. That's easy.
Where exactly in the Makefile is that reflected? ISTM that the current patch already covers that, since the framwork* targets are not concerned with the bin directory.
The other is managing symlinks (python, python2, and python3) across framework bin directories; currently there's no infrastructure for that. That part will probably have to wait until PyCon.
What is the "framework bin directory"? The links are proposed for /usr/local/bin resp. /usr/bin. The proposed patch already manages these links across releases (the most recent install wins).
If you are concerned about multiple feature releases: this is not an issue, since the links are just proposed for Python 2.7 (distributions may also add them for 2.6 and earlier, but we are not going to make a release in that direction).
It may be that the PEP becomes irrelevant before it is widely accepted: if the sole remaining Python 2 version is 2.7, users may just as well refer to python2 as python2.7.
Regards, Martin
In article <4F3CD403.7070102@v.loewis.de>, "Martin v. Lowis" <martin@v.loewis.de> wrote:
There are two issues that I know of for OS X. One is just getting a python2 symlink into the bin directory of a framework build. That's easy.
Where exactly in the Makefile is that reflected? ISTM that the current patch already covers that, since the framwork* targets are not concerned with the bin directory.
When a framework build is enabled in configure, several additional targets from Mac/Makefile are called from the main Makefile. The creating of the links in the framework bin directory and in $prefix/bin (/usr/local/bin) are handled there. (See the checked in patch for 2.7 for gory details: http://hg.python.org/cpython/rev/499796937b7a)
The other is managing symlinks (python, python2, and python3) across framework bin directories; currently there's no infrastructure for that. That part will probably have to wait until PyCon.
What is the "framework bin directory"? The links are proposed for /usr/local/bin resp. /usr/bin. The proposed patch already manages these links across releases (the most recent install wins).
The framework bin directory is a bin directory within a framework. The default location for 2.7 is: /Library/Frameworks/Python.framework/Versions/2.7/bin This is where the python executable, aux programs like idle, 2to3, pydoc, python-config, as well as all Distutils-installed scripts go. Mac/Makefile and the Mac installer each optionally create symlinks from /usr/local/bin (default) to the items in the framework bin directory at build or install time for the standard items but not for subsequent Distutils-installed scripts. Normally, the /usr/local/bin links are not needed with framework builds as the framework bin directory is added to the user's $PATH during installation.
If you are concerned about multiple feature releases: this is not an issue, since the links are just proposed for Python 2.7 (distributions may also add them for 2.6 and earlier, but we are not going to make a release in that direction).
It is more of an issue for multiple Python 3 versions. But the whole mechanism of managing multiple framework versions (2 and/or 3) is messy right now. But that's a separate topic that I plan to address later. As for now, I believe all that is needed for PEP 394 is now checked-in. -- Ned Deily, nad@acm.org
On Wed, Feb 15, 2012 at 12:44 AM, Barry Warsaw <barry@python.org> wrote:
On Feb 14, 2012, at 12:38 PM, Nick Coghlan wrote:
I have no idea, and I'm not going to open that can of worms for this PEP. We need to say something about the executable aliases so that people can eventually write cross-platform python2 shebang lines, but how particular distros actually manage the transition is going to depend more on their infrastructure and community than it is anything to do with us.
Then I think all the PEP needs to say is that it is explicitly up to the distros to determine if, when, where, and how they transition. I.e. take it off of python-dev's plate.
It turns out I'd forgotten what was in the PEP - the Notes section already contained a lot of suggestions along those lines. I changed the title of the section to "Migration Notes", but tried to make it clear that those *aren't* consensus recommendations, just ideas distros may want to think about when considering making the switch. The updated version is live on python.org: http://www.python.org/dev/peps/pep-0394/ I didn't end up giving an explicit rationale for the choice to use a symlink chain, since it really isn't that important to the main purpose of the PEP (i.e. encouraging distros to make sure "python2" is on the system path somewhere). Once MvL or Guido give the nod to the latest version, I'll bump it up to approved. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Feb 16, 2012, at 09:54 PM, Nick Coghlan wrote:
It turns out I'd forgotten what was in the PEP - the Notes section already contained a lot of suggestions along those lines. I changed the title of the section to "Migration Notes", but tried to make it clear that those *aren't* consensus recommendations, just ideas distros may want to think about when considering making the switch.
The updated version is live on python.org: http://www.python.org/dev/peps/pep-0394/
That section looks great Nick, thanks. I have one very minor quibble left. In many places the PEP says something like: "For the time being, it is recommended that python should refer to python2 (however, some distributions have already chosen otherwise; see the Rationale and Migration Notes below)." which implies that we may change our recommendation, but never quite says what the mechanism is for us to do that. You could change the status of this PEP from Draft to Active, which perhaps implies a little more strongly that this PEP will be updated should our recommendation ever change. I suspect it won't though (or at least won't any time soon). If you mark the PEP as Final, we still have the option of updating the PEP some time later to reflect new recommendations. It might be worth a quick sentence to that effect in the PEP. As I say though, this is a very minor quibble, so just DTRT. +1 and thanks for your great work on it. Cheers, -Barry
In article <CADiSq7cfuZ=22zcGkvcT4TH+GjjTaHHAh9XK6jUBwZv=aLuiKQ@mail.gmail.com>, Nick Coghlan <ncoghlan@gmail.com> wrote:
PEP 394 [1] aims to document our collective recommendation for allowing shebang lines to specifically request some version of 2.x, without requiring that it be exactly 2.7 (or 2.6, etc).
I'd let this drift for a while, but the imminent release of 2.7.3 makes it necessary to push for a final pronouncement. Kerrick has the necessary Makefile.pre.in patch up on the tracker [2] to add the hard link for the python2 name.
We could, of course, make the recommendation to distributions without updating "make install" and "make bininstall" to follow our own advice, but that seems needlessly inconsistent.
BTW, the patch is not sufficient to do all the right things for OS X intstaller builds, so, if you are thinking of approving this for 2.7.3, I'll need a few hours to develop and test the patch for that prior to code freeze, once there is agreement what it should do. Is there any work needed on the Windows installer side? -- Ned Deily, nad@acm.org
participants (10)
-
"Martin v. Löwis" -
Antoine Pitrou -
Barry Warsaw -
Cameron Simpson -
Charles-François Natali -
Guido van Rossum -
Matt Joiner -
Ned Deily -
Neil Schemenauer -
Nick Coghlan