Re: [Python-Dev] #!/usr/bin/env python --> python3 where applicable
Nick Coghlan wrote: Steven Bethard wrote: On Sat, Apr 18, 2009 at 9:37 PM, Nick Coghlan wrote: Note that such an approach would then require an altaltinstall command in order to be able to install a specific version of python 3.x without changing the python3 alias (e.g. installing 3.2 without overriding 3.1). I wasn't suggesting that there shouldn't be a "python3.1", "python3.2", etc. I'm more concerned about "fullinstall" creating "python3" instead of regular "python". If I understand Tony's summary correctly, the situation after Benjamin's latest checkin is as follows: 2.x altinstall: - installs python2.x executable 2.x fullinstall (default for "make install"): - installs python2.x executable - adjusts (or creates) python symlink to new executable 3.x altinstall (default for "make install"): - installs python3.x executable - adjusts (or creates) python3 symlink to new executable 3.x fullinstall: - installs python3.x executable - adjusts (or creates) python3 symlink to new executable - adjusts (or creates) python symlink to new executable With that setup, I'm sure we're going to get people complaining that 'altinstall' of 3.2 broke their python3 symlink from 3.1. If there are going to be 3 levels of executable naming (python3.x, python3, python), there needs to be 3 levels of installation rather than the traditional 2. For example, add a new target "py3install" and make that the default for 3.1: 3.x altinstall: - installs python3.x executable 3.x py3install (default for "make install"): - installs python3.x executable - adjusts (or creates) python3 symlink to new executable 3.x fullinstall: - installs python3.x executable - adjusts (or creates) python3 symlink to new executable - adjusts (or creates) python symlink to new executable Adjusting the python2 installs to do something similar with symlinks to python2 would also be useful when python3 becomes the standard python and python2 is used for legacy. I.e. 2.x altinstall: - installs python2.x executable 2.x py2install (default for "make install"): - installs python2.x executable - adjusts (or creates) python2 symlink to new executable 2.x fullinstall (default for "make install"): - installs python2.x executable - adjusts (or creates) python2 symlink to new executable - adjusts (or creates) python symlink to new executable Allan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #!/usr/bin/env python --> python3 where applicable
Allan McRae wrote: Nick Coghlan wrote: Steven Bethard wrote: On Sat, Apr 18, 2009 at 9:37 PM, Nick Coghlan wrote: Note that such an approach would then require an altaltinstall command in order to be able to install a specific version of python 3.x without changing the python3 alias (e.g. installing 3.2 without overriding 3.1). I wasn't suggesting that there shouldn't be a "python3.1", "python3.2", etc. I'm more concerned about "fullinstall" creating "python3" instead of regular "python". If I understand Tony's summary correctly, the situation after Benjamin's latest checkin is as follows: 2.x altinstall: - installs python2.x executable 2.x fullinstall (default for "make install"): - installs python2.x executable - adjusts (or creates) python symlink to new executable 3.x altinstall (default for "make install"): - installs python3.x executable - adjusts (or creates) python3 symlink to new executable 3.x fullinstall: - installs python3.x executable - adjusts (or creates) python3 symlink to new executable - adjusts (or creates) python symlink to new executable With that setup, I'm sure we're going to get people complaining that 'altinstall' of 3.2 broke their python3 symlink from 3.1. If there are going to be 3 levels of executable naming (python3.x, python3, python), there needs to be 3 levels of installation rather than the traditional 2. For example, add a new target "py3install" and make that the default for 3.1: 3.x altinstall: - installs python3.x executable 3.x py3install (default for "make install"): - installs python3.x executable - adjusts (or creates) python3 symlink to new executable 3.x fullinstall: - installs python3.x executable - adjusts (or creates) python3 symlink to new executable - adjusts (or creates) python symlink to new executable Adjusting the python2 installs to do something similar with symlinks to python2 would also be useful when python3 becomes the standard python and python2 is used for legacy. I.e. 2.x altinstall: - installs python2.x executable 2.x py2install (default for "make install"): And of course that was supposed to say "future default"... - installs python2.x executable - adjusts (or creates) python2 symlink to new executable 2.x fullinstall (default for "make install"): - installs python2.x executable - adjusts (or creates) python2 symlink to new executable - adjusts (or creates) python symlink to new executable ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python-3 transition in Arch Linux
Hi, While this is not strictly related to python development, I thought that developers of python might be interested in some of the lessons provided by this. So forgive me if this is really wrong for this list... Recently Arch Linux did a big transition with respect to python. Now we support two python packages: "python" and "python2". The "python" package will always contain the latest 3.x release and currently has /usr/bin/python3.1 with symlinks to /usr/bin/python3 and /usr/bin/python. The "python2" package contains the latest from the "legacy" python-2.x branch and has /usr/bin/python2.7 with a symlink to /usr/bin/python2. I really do not want to debate the sanity of pointing /usr/bin/python at python-3.x here, but it suffices to say that I am of the opinion that if python-3.x is really the future of python, then /usr/bin/python must eventually point to a 3.x version. Also, Arch Linux is very bleeding edge and we expect our users to be competent enough to deal with thing like this. According to #python, we are all idiots And I have been (figuratively) yelled at by a couple of Debian developers (which is incidentally the only major distro I found without a /usr/bin/python2 symlink). Anyway, this transition was rather simple from a distribution point of view apart from the sheer number of packages involved. All our supported packages were rebuilt to work with that symlink layout and any "porting" software to use that layout was relatively simple. Most packages either detected the python2 symlink during the rebuild and just worked while others required some sort "export PYTHON=python2" or "--with-python=python2" or "python2 setup.py" or the like during the build. Software packages tend to fall into three categories at roughly equal frequencies: 1) packages that detected or were pointed at python2 and everything worked 2) packages that detected or were pointed at python2 and partially worked 3) packages that needed adjustment to work with the python2 symlink. The second case was particularly interesting. These software would change some of their #! to point at the python2 symlink and leave the rest pointing at python. Note that python-2.7 itself falls into this category as many files in /usr/lib/python2.7 still have "#!/usr/bin/env python" even when installed with "make altinstall". I can not remember the exact details, but I recall that some of these files were installed with executable permissions which would be bad, but I need to look into this again now things have calmed down... The packages that did not auto-detect and work with /usr/bin/python2 or /usr/bin/python2.7 mostly required a sed of their shebangs or a patch to any hardcoded /usr/bin/python paths so were easily fixed. So that is something that python software developers could think about for the future. When someone configures a module using a particular version of python, then ALL shebangs need changed to use that version. And it is generally bad practice to hardcode /usr/bin/python into any application as you are never quite sure which version you are getting. Instead allow it to be configured, keeping the current value as default. Cheers, Allan -- Allan McRae Arch Linux Developer ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3 transition in Arch Linux
On 05/11/10 08:40, Laurens Van Houtven wrote: On Thu, Nov 4, 2010 at 5:44 AM, Allan McRae wrote: According to #python, we are all idiots I realize this is not really what your message was about and for sake of brevity you used a bit of a hyperbole, but like Thomas I would still like to nip in right there. #python is a pretty big channel. I think everyone understands that reducing it in its entirety to a single opinion as inflammatory as "you're all idiots" is at best oversimplifying and at worst offensive. Of course, and I was not intending to offend here. It was more of a running commentary on the unintended influx of Arch Linux users to the channel and some of the responses posted to them (some of which I found rather amusing when forwarded to me - especially the early response as people were figuring out what was going on). I also agree with the "NO ARCH" topic at the moment. I was fairly surprised so many people went to #python for help given we had made news posts and had a topic in our IRC channel pointing to how to start fixing issues. Allan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3 transition in Arch Linux
On 05/11/10 11:20, Jesus Cea wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/11/10 05:44, Allan McRae wrote: The second case was particularly interesting. These software would change some of their #! to point at the python2 symlink and leave the rest pointing at python. Note that python-2.7 itself falls into this category as many files in /usr/lib/python2.7 still have "#!/usr/bin/env python" even when installed with "make altinstall". I can not remember the exact details, but I recall that some of these files were installed with executable permissions which would be bad, but I need to look into this again now things have calmed down... PLEASE, open a bug with this. It is a serious bug. "make altinstall" *SHOULD* be respected. Done: http://bugs.python.org/issue10318 Allan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3 transition in Arch Linux
On 05/11/10 18:47, Thomas Wouters wrote: No, that's not my point at all. The problem isn't that Python 3 is incompatible with Python 2. The problem is that stuff broke without (apparently) fair warning. Just to clarify (and going way off topic for this list...), this was discussed on the Arch Linux mailing lists around six months in advance, then again about two months beforehand when the rebuild started. Then it sat in our testing repository for a month where issues were discussed on our mailing lists and forums. Also a news post was made on our website front page before moving it into our main repos. With a rolling release distro we do not have the luxury of making release notes every major release so we make it abundantly clear to our users that we expect them to at least always read the front page news before updating. There are even wrapper scripts for our package manager that print the news headlines before updating. So there was warning. As always, it was just ignored by a portion of our users. Allan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream
On 02/03/11 08:06, Guido van Rossum wrote: On Tue, Mar 1, 2011 at 1:26 PM, Eric Smith wrote: On 3/1/2011 4:19 PM, Kerrick Staley wrote: Hello, There is a need for the default Python2 install to place a symlink at /usr/bin/python2 that points to /usr/bin/python, or for the documentation to recommend that packagers ensure that python2 is defined. Also, all documentation should be changed to recommend that "#!/usr/bin/env python2" be used as the shebang for Python 2 scripts. This is needed because some distributions (Arch Linux, in particular), point /usr/bin/python to /usr/bin/python3, while others (including Slackware, Debian, and the BSDs, probably more) do not even define the python2 command. This means that a script has no way of achieving cross-platform compatibility. The point at which many distributions begin to alias /usr/bin/python to /usr/bin/python3 is due soon, and for the next couple of years, it would be best to use a python2 or python3 shebang in all scripts, making no assumptions about plain python, which should only be invoked interactively. This email from about 3 years ago seems relevant: : http://mail.python.org/pipermail/python-3000/2008-March/012421.html Again, this issue needs to be addressed by the Python developers themselves so that different *nix distributions will handle it consistently, allowing Python scripts to continue to be cross-platform. I believe we agreed at the language summit last year (or maybe even the year before) that "python" would always be python2.x, and "python3" would be python3.x. And by "always" we indeed meant forever. To do otherwise would break scripts even many, many years from now. Unfortunately distros are not following these guidelines. As long as we still have the pythonX.Y links I think it's better to have "python2", "python3" and "python" than total anarchy. This was brought up when Arch Linux switched /usr/bin/python to point a python3 around six months ago, and at the time no-one could actually recall the decision to always point /usr/bin/python at python2 forever. In fact, the only decision that was clearly made (and acted on) was that "make install" for python3 would install /usr/bin/python3. e.g. http://www.mail-archive.com/python-dev@python.org/msg53204.html But if that decision was made, it was not documented anywhere that I can find, so effectively was a non-decision... Deciding that /usr/bin/python going to always point at python2 just makes me think that python3 is always going to be a second class citizen. Eventually python-2.7 will be long gone and it would seem wrong for people will still be using "python3" to run their scripts once python-3.xx is the primary python version. So a transition is going to need to be made here at some stage. Most distributions have been providing the /usr/bin/python2 symlink for a long time, with Debian being the notable exception. I think adding such a symlink is in the realm of what distribution packagers can choose to do on their own, but having it done automatically for python-2.7 would also be of benefit. Allan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream
On 03/03/11 00:03, Piotr Ożarowski wrote: [Sandro Tosi, 2011-03-02] On Wed, Mar 2, 2011 at 13:56, Piotr Ożarowski wrote: [Sandro Tosi, 2011-03-02] On Wed, Mar 2, 2011 at 10:01, Piotr Ożarowski wrote: I co-maintain with Matthias a package that provides /usr/bin/python symlink in Debian and I can confirm that it will always point to Python 2.X. We also do not plan to add /usr/bin/python2 symlink (and I guess only accepted PEP can change that) Can you please explain why you NACK this proposed change? it encourages people to change /usr/bin/python symlink to point to python3.X which I'm strongly against (how can I tell that upstream author meant python3.X and not python2.X without checking the code?) with 'people' do you mean 'users'? if so, isn't this risk already present? users already break their systems via "sudo ez_install ..." (note the "sudo" part!), I meant developers (distro and upstream authors). If a programmer develops a script in Python 3 on Arch and later ships his file with /usr/bin/python in shebang, it's very likely that this script will not work on all distributions that didn't (yet?) change the symlink. If you, user, change the python symlink (provided by python-minimal in Debian) to something else than what's shipped, it's still a local change, and will never be supported; but with python2 *Debian is free* to decide if python can be pointed to python3, if the time will come. ... and make other distributions developers' life miserable? But is that not the whole point of adding the /usr/bin/python2 symlink. That way a developer can explicitly use a /usr/bin/python2 or /usr/bin/python3 shebang and have it portable everywhere. At the moment, Debian seems to be the major hold-up on that actually being a reality being the only major distro I could find that does not provide such a symlink. Note also that even restricting /usr/bin/python to point at a python-2.x binary gives no guarantee on what actual python-2.x version you are getting, so it is not as if guaranteeing portability is not a problem already... Allan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream
On 03/03/11 00:29, Piotr Ożarowski wrote: [Allan McRae, 2011-03-02] But is that not the whole point of adding the /usr/bin/python2 symlink. That way a developer can explicitly use a /usr/bin/python2 or /usr/bin/python3 shebang and have it portable everywhere. At the moment, Debian seems to be the major hold-up on that actually being a reality being the only major distro I could find that does not provide such a symlink. Do you realize how many (still perfectly usable) scripts written in Python 2.x few years ago (and not modified since then) are out there? Do you realize how much work would it require to fix every single one of them to point to /usr/bin/python2 instead? Even if we'd start checking mdate and change it at build time automatically, there still will be way too many false positives... for no clear gain. Having made the packages using python-2.x code from an entire distribution point at /usr/bin/python2, I have a fair idea of how much work is involved... And that is exactly why changes need made now so that time is available for transition. Providing the /usr/bin/python2 symlink now means that any future code would be able to point to it rather than some unversioned python binary. That way in ?? years when python-3.x is "the" python and python-2.x is obsolete, and it is decided that /usr/bin/python will be python-3.x (which I believe is the only logical outcome), then everyone will be a lot more prepared. Allan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
