Re: [arch-general] a plea for python 2
take a look at the kedpm PKGBUILD [1], the package have /usr/bin/python as shebang, but if you run: python2 setup.py the script will automatically fix the shebangs to /usr/bin/python2 before installing ** [1] https://aur.archlinux.org/packages/ke/kedpm/PKGBUILD On Fri, Dec 16, 2011 at 5:30 AM, C Anthony Risinger anth...@xtfx.me wrote: On Thu, Dec 15, 2011 at 9:51 AM, Alex Bolgarov a...@bolgarov.org wrote: you all think the proper fix is for me to put in the docs something like on Arch systems you need to do [x] before building, whether [x] is get the PKGBUILD with the patch from AUR or even run the sed-python-with-python2.sh included in the distribution. I personally don't think it is a proper fix - I think it is not a fix at all. My opinion is that Python3 is sufficiently different from Python2 to be considered a new language, not just a new version of old (thus it would be appropriate to use new name, 'python3', for it, leaving 'python' forever referring to python2). (That is, desire to be on the bleeding edge does not warrant breaking existing software) http://mail.python.org/pipermail/python-dev/2011-March/108562.html ... the thread starts here: http://mail.python.org/pipermail/python-dev/2011-March/108491.html ... if it hasn't been linked already. that discussion led to the aforementioned PEP, and was generally well-received (hence creation of the PEP). If I were you, I would probably stop putting shebangs into my Python scripts (so that they would be not executables), and write a shell wrapper script for every python script that figures out during runtime how python2 executable is called, and call python2 script using this python executables (or write single script with symbolic links to it with different names and use $0 shell variable to find which python script to call). you can factor out pieces into separate files and selectively import based on various criteria, like any other module. create an small bootstrap file that is python2/3 compatible and either run/import according to the binary you're running under, or re-exec under a different one (slightly rude form a user's perspective, but possible). a little funky, but you can test syntax using eval: http://stackoverflow.com/questions/446052/python-best-way-to-check-for-python-version-in-program-that-uses-new-language-f/446061#446061 ... and catch SyntaxError. per: http://mail.python.org/pipermail/python-dev/2011-March/108495.html http://mail.python.org/pipermail/python-dev/2011-March/108499.html ... not sure if that's changed, but Arch isn't alone ... there was an incubation period of a couple years, until 3.2 release, for applications/libraries to catch up. python3 is here now, so let's give her a big welcome, and move on ;-) -- C Anthony
Re: [arch-general] a plea for python 2
On Thu, Dec 15, 2011 at 9:51 AM, Alex Bolgarov a...@bolgarov.org wrote: you all think the proper fix is for me to put in the docs something like on Arch systems you need to do [x] before building, whether [x] is get the PKGBUILD with the patch from AUR or even run the sed-python-with-python2.sh included in the distribution. I personally don't think it is a proper fix - I think it is not a fix at all. My opinion is that Python3 is sufficiently different from Python2 to be considered a new language, not just a new version of old (thus it would be appropriate to use new name, 'python3', for it, leaving 'python' forever referring to python2). (That is, desire to be on the bleeding edge does not warrant breaking existing software) http://mail.python.org/pipermail/python-dev/2011-March/108562.html ... the thread starts here: http://mail.python.org/pipermail/python-dev/2011-March/108491.html ... if it hasn't been linked already. that discussion led to the aforementioned PEP, and was generally well-received (hence creation of the PEP). If I were you, I would probably stop putting shebangs into my Python scripts (so that they would be not executables), and write a shell wrapper script for every python script that figures out during runtime how python2 executable is called, and call python2 script using this python executables (or write single script with symbolic links to it with different names and use $0 shell variable to find which python script to call). you can factor out pieces into separate files and selectively import based on various criteria, like any other module. create an small bootstrap file that is python2/3 compatible and either run/import according to the binary you're running under, or re-exec under a different one (slightly rude form a user's perspective, but possible). a little funky, but you can test syntax using eval: http://stackoverflow.com/questions/446052/python-best-way-to-check-for-python-version-in-program-that-uses-new-language-f/446061#446061 ... and catch SyntaxError. per: http://mail.python.org/pipermail/python-dev/2011-March/108495.html http://mail.python.org/pipermail/python-dev/2011-March/108499.html ... not sure if that's changed, but Arch isn't alone ... there was an incubation period of a couple years, until 3.2 release, for applications/libraries to catch up. python3 is here now, so let's give her a big welcome, and move on ;-) -- C Anthony
Re: [arch-general] a plea for python 2
Or use #!/usr/bin/env python2. This should fix problems like python2 being in a different path among distribution. On 15 December 2011 17:51, Alex Bolgarov a...@bolgarov.org wrote: you all think the proper fix is for me to put in the docs something like on Arch systems you need to do [x] before building, whether [x] is get the PKGBUILD with the patch from AUR or even run the sed-python-with-python2.sh included in the distribution. I personally don't think it is a proper fix - I think it is not a fix at all. My opinion is that Python3 is sufficiently different from Python2 to be considered a new language, not just a new version of old (thus it would be appropriate to use new name, 'python3', for it, leaving 'python' forever referring to python2). (That is, desire to be on the bleeding edge does not warrant breaking existing software) If I were you, I would probably stop putting shebangs into my Python scripts (so that they would be not executables), and write a shell wrapper script for every python script that figures out during runtime how python2 executable is called, and call python2 script using this python executables (or write single script with symbolic links to it with different names and use $0 shell variable to find which python script to call).
Re: [arch-general] a plea for python 2
Sorry I meant 'in a different path among distributions'. Forgot to double-check. On 15 December 2011 17:56, Thanasis Georgiou sakisd...@gmail.com wrote: Or use #!/usr/bin/env python2. This should fix problems like python2 being in a different path among distribution.
Re: [arch-general] a plea for python 2
+1 to archlinux initiative. Someone has to be the first and as always arch is there. Actually python, read python3, as default is one of the reasons I use arch. Hector On 15 December 2011 17:58, Thanasis Georgiou sakisd...@gmail.com wrote: Sorry I meant 'in a different path among distributions'. Forgot to double-check. On 15 December 2011 17:56, Thanasis Georgiou sakisd...@gmail.com wrote: Or use #!/usr/bin/env python2. This should fix problems like python2 being in a different path among distribution. -- Hector Martínez-Seara Monné mail: hse...@gmail.com Tel: +34656271145 Tel: +358442709253
Re: [arch-general] a plea for python 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15/12/11 14:20, Hector Martinez-Seara wrote: +1 to archlinux initiative. Someone has to be the first and as always arch is there. Actually python, read python3, as default is one of the reasons I use arch. Hector On 15 December 2011 17:58, Thanasis Georgiou sakisd...@gmail.com wrote: Sorry I meant 'in a different path among distributions'. Forgot to double-check. On 15 December 2011 17:56, Thanasis Georgiou sakisd...@gmail.com wrote: Or use #!/usr/bin/env python2. This should fix problems like python2 being in a different path among distribution. Guys (Thanasis and Hector), I beg you, stop the top-posting, it's hard to understand the whole thread when you do that thing. Thanks. - -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO6jAdAAoJEEKh2xXsEzutl2QH/07ZA1xvOBjetzwxGhC/HVs+ i+sLdrEfcIg7VYP7kwRues8cG0RGa1BHMdIvcLD1FSWGPi7MXxwzwxbLf0LbnHdq n8xJBbn+zm9+pLK718jeKV3+EKRjnnMsbdK5O6aHSa0wnueFDKk2BhKtDxexCGk3 2bohOt+EKsaEg9/JBQNYvLPB2PiCnWe4mpmXwq1CGTB1nH02QTRZVsolx9UXGT0R qYWqbXFdhUgParqCewvalXAshn+/ySVg0BpTXz7/rNZDy/WKJDu1ACPVrgPbaxVc aYozjQxYzw3ELJNGfh8tIe5qjlETVskDpkrF5CadA4lqhQ+35r2VLP0Tf1qVoq0= =art4 -END PGP SIGNATURE-
Re: [arch-general] a plea for python 2
python2 will refer to some version of Python 2.x python3 will refer to some version of Python 3.x python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions above snippet taken from: http://www.python.org/dev/peps/pep-0394/
Re: [arch-general] a plea for python 2
I think the question was whether it was a good idea (tm) to alias python to python3 instead of python2. Then again, you can easily change the alias yourself... Sander On Wed, Dec 14, 2011 at 4:39 PM, Thomas Dziedzic gos...@gmail.com wrote: python2 will refer to some version of Python 2.x python3 will refer to some version of Python 3.x python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions above snippet taken from: http://www.python.org/dev/peps/pep-0394/
Re: [arch-general] a plea for python 2
On 12/14/2011 05:24 PM, Evan Martin wrote: 1) Is it intentional that I am unable to use software from upstream like Django unmodified? Am I expected to only install software from the Arch repositories, where it has been patched by Arch devs to work on Arch? (See below for more on Django.) I don't profess to speak for the Arch devs - so please take the following as my opinion, not the official Arch answer. But as a long-time Arch user, my opinion would be that the answer to both those questions is a) yes, and b) I don't really see that as a problem. Many/most distros apply some patches to upstream software. Arch does as well, but generally tries to do so as minimally as possible. In addition, Arch tries to run as bleeding-edge software as possible. That's resulting in the situation you're describing: Arch uses Python3, but some upstream packages have not been upgraded for that yet. So Arch packages need to be temporarily patched to get around that. Otherwise the packages will be broken. Seems like a reasonable reason to apply a patch to me. Also, I think the general intention with Arch is that you will install software from packages in the repositories (or the AUR). It's not generally expected (or supported) for you to randomly install software directly from source code. So probably the Arch way to solve the issue posed in your question above would be: * Use ABS to get a copy of the Arch PKGBUILD for whatever package is in question * Create your own copy/version of that PKGBUILD and tweak as needed to support whatever non-standard functionality you're trying to achieve * Build the package and install * Realize that you're on your own from here on out. If you're running a non-standard version of a package, then the responsibility for supporting it / fixing incompatibilities bugs is yours. You can't expect that your non-standard package will automatically remain compatible with all future updates to the standard Arch packages. Dissent welcome. HTH, DR
Re: [arch-general] a plea for python 2
Am 14.12.2011 23:24, schrieb Evan Martin: What I don't understand is why you're manually patching upstream software to rewrite references from /usr/bin/python to /usr/bin/python2. This sort of forking is exactly the sort of divergence (like how Ubuntu modified their GTK to add their own specific hooks) that I was fleeing from when I came to Arch. There's no forking here. Python 2 is end-of-life, python 3 is current. Applications that set a 'python' shebang, but require 'python2' are *broken*, we *fix* them. signature.asc Description: OpenPGP digital signature
Re: [arch-general] a plea for python 2
On Wed, Dec 14, 2011 at 11:57 PM, Oon-Ee Ng ngoonee.t...@gmail.com wrote: On Thu, Dec 15, 2011 at 6:54 AM, Sander Jansen s.jan...@gmail.com wrote: I think the question was whether it was a good idea (tm) to alias python to python3 instead of python2. Then again, you can easily change the alias yourself... Sander Bottom-posting, please. And I believe rather than discuss this all over again referencing the original discussion(s) about this would help? I know there was one on this ML and another on the forums (no time to look them up now, sorry). http://mailman.archlinux.org/pipermail/arch-general/2010-October/016807.html http://mailman.archlinux.org/pipermail/arch-announce/2011-February/000276.html
Re: [arch-general] a plea for python 2
On Wed, Dec 14, 2011 at 5:00 PM, Thomas Bächler tho...@archlinux.org wrote: Am 14.12.2011 23:24, schrieb Evan Martin: What I don't understand is why you're manually patching upstream software to rewrite references from /usr/bin/python to /usr/bin/python2. This sort of forking is exactly the sort of divergence (like how Ubuntu modified their GTK to add their own specific hooks) that I was fleeing from when I came to Arch. There's no forking here. Python 2 is end-of-life, python 3 is current. Applications that set a 'python' shebang, but require 'python2' are *broken*, we *fix* them. This is how I feel about the current situation also. The pep clearly defines that you should only be using python2 or python3 in your shebangs, and that python should be ideally used only to invoke interactive sessions. The fact that programmers and distro python packagers ignore this is not our fault.
Re: [arch-general] a plea for python 2
On Wed, Dec 14, 2011 at 5:05 PM, Thomas Dziedzic gos...@gmail.com wrote: On Wed, Dec 14, 2011 at 5:00 PM, Thomas Bächler tho...@archlinux.org wrote: Am 14.12.2011 23:24, schrieb Evan Martin: What I don't understand is why you're manually patching upstream software to rewrite references from /usr/bin/python to /usr/bin/python2. This sort of forking is exactly the sort of divergence (like how Ubuntu modified their GTK to add their own specific hooks) that I was fleeing from when I came to Arch. There's no forking here. Python 2 is end-of-life, python 3 is current. Applications that set a 'python' shebang, but require 'python2' are *broken*, we *fix* them. This is how I feel about the current situation also. The pep clearly defines that you should only be using python2 or python3 in your shebangs, and that python should be ideally used only to invoke interactive sessions. The fact that programmers and distro python packagers ignore this is not our fault. Until the conventions described in this PEP are more widely adopted, having python invoke python2 will remain the recommended option.
Re: [arch-general] a plea for python 2
On Wed, Dec 14, 2011 at 5:19 PM, Sander Jansen s.jan...@gmail.com wrote: On Wed, Dec 14, 2011 at 5:05 PM, Thomas Dziedzic gos...@gmail.com wrote: On Wed, Dec 14, 2011 at 5:00 PM, Thomas Bächler tho...@archlinux.org wrote: Am 14.12.2011 23:24, schrieb Evan Martin: What I don't understand is why you're manually patching upstream software to rewrite references from /usr/bin/python to /usr/bin/python2. This sort of forking is exactly the sort of divergence (like how Ubuntu modified their GTK to add their own specific hooks) that I was fleeing from when I came to Arch. There's no forking here. Python 2 is end-of-life, python 3 is current. Applications that set a 'python' shebang, but require 'python2' are *broken*, we *fix* them. This is how I feel about the current situation also. The pep clearly defines that you should only be using python2 or python3 in your shebangs, and that python should be ideally used only to invoke interactive sessions. The fact that programmers and distro python packagers ignore this is not our fault. Until the conventions described in this PEP are more widely adopted, having python invoke python2 will remain the recommended option. The full quote is: More conservative distributions that are less willing to tolerate breakage of third party scripts continue to alias it to python2. Until the conventions described in this PEP are more widely adopted, having python invoke python2 will remain the recommended option. Also, when do you suppose widely adopted will occur? If you leave space for interpretation, then expect opinions that don't match yours. This is a recommendation and someone is going to have to take the first step eventually. Here is a metaphor in the spirit of the season: Arch is the snowplow that is shoveling the snow to the sides of the road to make it easier for other distros to pass. I see this thread turning into the threads when it was first announced, and I refuse to go down that path, again... Here is the python maintainer's blog post about it: http://allanmcrae.com/2011/03/the-python2-pep/ Cheers!
Re: [arch-general] a plea for python 2
On 15 December 2011 07:44, Thomas Dziedzic gos...@gmail.com wrote: On Wed, Dec 14, 2011 at 5:19 PM, Sander Jansen s.jan...@gmail.com wrote: On Wed, Dec 14, 2011 at 5:05 PM, Thomas Dziedzic gos...@gmail.com wrote: On Wed, Dec 14, 2011 at 5:00 PM, Thomas Bächler tho...@archlinux.org wrote: Am 14.12.2011 23:24, schrieb Evan Martin: What I don't understand is why you're manually patching upstream software to rewrite references from /usr/bin/python to /usr/bin/python2. This sort of forking is exactly the sort of divergence (like how Ubuntu modified their GTK to add their own specific hooks) that I was fleeing from when I came to Arch. There's no forking here. Python 2 is end-of-life, python 3 is current. Applications that set a 'python' shebang, but require 'python2' are *broken*, we *fix* them. This is how I feel about the current situation also. The pep clearly defines that you should only be using python2 or python3 in your shebangs, and that python should be ideally used only to invoke interactive sessions. The fact that programmers and distro python packagers ignore this is not our fault. Until the conventions described in this PEP are more widely adopted, having python invoke python2 will remain the recommended option. The full quote is: More conservative distributions that are less willing to tolerate breakage of third party scripts continue to alias it to python2. Until the conventions described in this PEP are more widely adopted, having python invoke python2 will remain the recommended option. Also, when do you suppose widely adopted will occur? If you leave space for interpretation, then expect opinions that don't match yours. This is a recommendation and someone is going to have to take the first step eventually. Here is a metaphor in the spirit of the season: Arch is the snowplow that is shoveling the snow to the sides of the road to make it easier for other distros to pass. I see this thread turning into the threads when it was first announced, and I refuse to go down that path, again... Here is the python maintainer's blog post about it: http://allanmcrae.com/2011/03/the-python2-pep/ Cheers! To sum up the two Thomas' replies above (which have been mentioned a number of times before): 1) Arch faces the pain before anyone else. 2) Arch fixes stuff for real, _not_ enhances. (which is what you mean by Ubuntu-like patching) Using /usr/bin/python is no longer recommended as upstream has realised the mess they themselves have made. All software developers who consider themselves up-to-date with technology should adopt these latest changes, or choose to be backdated. -- GPG/PGP ID: C0711BF1
Re: [arch-general] a plea for python 2
On Wed, Dec 14, 2011 at 5:24 PM, Evan Martin mart...@danga.com wrote:
As a software developer, I am now getting contacted by users where my
software doesn't work on Arch. I even applied a patch submitted by an
Arch user to make my code use python2 only to discover it broke my
software on Mac and Windows.
To give an alternate to the already present Code-correctness answers, I
might suggest A) contacting those distributing Windows and Mac binaries to
include the appropriate support for python2, or B) Accept doing it wrong
(sticking to python, not python2) and forcing Arch users to patch as
needed. I might suggest B since Arch users likely won't be afraid to patch
your program (or others' programs), and your program will probably be
installed via the AUR using a PKGBUILD that patches it (hopefully well).
2) Should I change the software I write to attempt to detect when I'm
on an Arch system and adjust scripts/etc. accordingly? (I can't just
fix it because there is no /usr/bin/python2 on existing systems like
Macs.)
It sounds (from the rest of this thread and your statement above) like
you'd need to detect Mac vs. Windows vs. Linux, really, which reduces the
complexity of your code. Or you can leave Arch and its users to fend for
itself. Or you could have a development version that is for the bleeding
edge, and a script to modify everything appropriately. Or any number of
other solutions.
- Here's a project of mine where on AUR they've attempted to patch
around the python/python2 thing in the PKGBUILD:
http://aur.archlinux.org/packages/ni/ninja-git/PKGBUILD
However, the patch is not sufficient, which lead to another bug report.
I don't do much python and I know nothing about your project specifically,
but it seems to me like a find and sed. Something like
find . -type f 'sed' '-e' '1s/python[^23]/python2/' '{}' \;
But I could just be ignorant about some subtleties. Regardless, just give
it time. Some Archer will either fix it eventually or complain so another
Archer fixes it. Or suggest a better fix for your software yourself. The
need to patch this one line should not make or break your software in terms
of use. Though, again, I could just be spouting ignorance.
MAQ.
Re: [arch-general] a plea for python 2
On Wed, Dec 14, 2011 at 7:53 PM, Qadri muhammad.a.qa...@gmail.com wrote:
On Wed, Dec 14, 2011 at 5:24 PM, Evan Martin mart...@danga.com wrote:
As a software developer, I am now getting contacted by users where my
software doesn't work on Arch. I even applied a patch submitted by an
Arch user to make my code use python2 only to discover it broke my
software on Mac and Windows.
To give an alternate to the already present Code-correctness answers, I
might suggest A) contacting those distributing Windows and Mac binaries to
include the appropriate support for python2, or B) Accept doing it wrong
(sticking to python, not python2) and forcing Arch users to patch as
needed. I might suggest B since Arch users likely won't be afraid to patch
your program (or others' programs), and your program will probably be
installed via the AUR using a PKGBUILD that patches it (hopefully well).
Thanks. Python is included on OS X, so I doubt A will work.
B does seem to be my only option. (What you call doing it wrong is
what I call what everyone except Arch does.)
- Here's a project of mine where on AUR they've attempted to patch
around the python/python2 thing in the PKGBUILD:
http://aur.archlinux.org/packages/ni/ninja-git/PKGBUILD
However, the patch is not sufficient, which lead to another bug report.
I don't do much python and I know nothing about your project specifically,
but it seems to me like a find and sed. Something like
find . -type f 'sed' '-e' '1s/python[^23]/python2/' '{}' \;
But I could just be ignorant about some subtleties. Regardless, just give
it time. Some Archer will either fix it eventually or complain so another
Archer fixes it. Or suggest a better fix for your software yourself. The
need to patch this one line should not make or break your software in terms
of use. Though, again, I could just be spouting ignorance.
Yes, a find and a sed would probably fix the problem. (The existing
AUR script fixes a compile-time dependency on python=python2, but
doesn't fix the run-time one.)
I just wanted to be certain that you all think the proper fix is for
me to put in the docs something like on Arch systems you need to do
[x] before building, whether [x] is get the PKGBUILD with the patch
from AUR or even run the sed-python-with-python2.sh included in the
distribution. It seems a little silly to me (breaking software
mostly inconveniences users, and in this particular case doesn't gain
you anything, as anyone who adds support for Python 3 could just as
well make their shebang mention it while they're changing other
things) but it's not my place to tell you what to do.
Re: [arch-general] a plea for python 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/12/11 19:24, Evan Martin wrote: Hello, I'm a recent Arch user, a refugee from Ubuntu. I was attracted to Arch because I was tired of Ubuntu forcing their new software on me -- it seemed the Arch way was to allow you to use bleeding edge if you wanted it, but to not fork upstream. So it was with some surprise that I discovered that Arch made /usr/bin/python point to something other than Python 2. This differs from every other system (not only other Linuxes, but also [as I learned from bug reports I received] OS X and even python.exe on Windows). Hi Evan, Welcome to Arch Linux, I don't know why many Ubuntu users are coming here just directly, makes me wonder what we can be a solution for problems for Ubuntu users. I appreciate that y'all want to use the bleeding edge, and it completely consistent with my understanding of Arch that you would only provide Python 3 by default as well as write your system scripts use Python 3. (I write this mail with some trepidation as I fear a response like STFU noob Arch is bleeding edge, which is emphatically not a response to the issue I'm actually raising.) Well in the FOSS World that kind of responses are known, but your mail seems decent to reply you that. What I don't understand is why you're manually patching upstream software to rewrite references from /usr/bin/python to /usr/bin/python2. This sort of forking is exactly the sort of divergence (like how Ubuntu modified their GTK to add their own specific hooks) that I was fleeing from when I came to Arch. :( You can see in the references below that it appears this is contrary to how upstream thinks it should work. Not necessary, you will see some people posting you some pep links about python and pytho3 It means that I can't download any random project (such as Chromium) and build it without first applying Arch-specific patches. And upstreams like Chromium can't change to support Arch's divergence without breaking their code on non-Arch systems. There are some apps that you will have to patch in order to work with any distro non-specified by them, I can remember patching oracle-xe like 4 or 6 years ago, cheating the installer with some Red Hat path in order to install. That is not our fault obviously. As a software developer, I am now getting contacted by users where my software doesn't work on Arch. I even applied a patch submitted by an Arch user to make my code use python2 only to discover it broke my software on Mac and Windows. So my questions for you are 1) Is it intentional that I am unable to use software from upstream like Django unmodified? Am I expected to only install software from the Arch repositories, where it has been patched by Arch devs to work on Arch? (See below for more on Django.) As a python developer i wonder why you don't use virtualenv [1]? virtualenv will solve you many problems, not only in Arch, for your development work with out-of-date or too updated python and libraries, after do the hello world, and run the pep8 the next step for a python developer should be to use virtualenv, in order to have best practices. 2) Should I change the software I write to attempt to detect when I'm on an Arch system and adjust scripts/etc. accordingly? (I can't just fix it because there is no /usr/bin/python2 on existing systems like Macs.) Again use virtualenvs [1] for your python development [1] http://pypi.python.org/pypi/virtualenv - -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO6X4pAAoJEEKh2xXsEzutHVcH/iO1wrXDb+SBJbJvc21pb6Zy 3VjEwps9aKpJknesLB6cR6S5TlBWpU+XgJMvPQXIObduN4Ejj3/8N1xbMmktCwZC YqzFMI1kXrchyUrSztN5tm8LhDf19ZgaazJziiqoc/uw4BxueT0FEQTO3LEK3cLy NUhCKl4Tvt2sDPcizAGh8FDDgsoSGs2jpEyWQ+MI+5cOpXj5Ry0TE1EZQuznCV+k PaN/bnDrItTQnay+bV/RB6yDdn34zGCjAnx3+bgd7fN8XdfpIyPCuu9WDjlRIq2J fvzXgqhjRP3O6lblBwoCGi1lV0mMav5q7PLsalz5g+6UOdXLYKnKOw6cfvamGfY= =aohR -END PGP SIGNATURE-
Re: [arch-general] a plea for python 2
On Wed, Dec 14, 2011 at 5:44 PM, Thomas Dziedzic gos...@gmail.com wrote: On Wed, Dec 14, 2011 at 5:19 PM, Sander Jansen s.jan...@gmail.com wrote: On Wed, Dec 14, 2011 at 5:05 PM, Thomas Dziedzic gos...@gmail.com wrote: On Wed, Dec 14, 2011 at 5:00 PM, Thomas Bächler tho...@archlinux.org wrote: Am 14.12.2011 23:24, schrieb Evan Martin: What I don't understand is why you're manually patching upstream software to rewrite references from /usr/bin/python to /usr/bin/python2. This sort of forking is exactly the sort of divergence (like how Ubuntu modified their GTK to add their own specific hooks) that I was fleeing from when I came to Arch. There's no forking here. Python 2 is end-of-life, python 3 is current. Applications that set a 'python' shebang, but require 'python2' are *broken*, we *fix* them. This is how I feel about the current situation also. The pep clearly defines that you should only be using python2 or python3 in your shebangs, and that python should be ideally used only to invoke interactive sessions. The fact that programmers and distro python packagers ignore this is not our fault. Until the conventions described in this PEP are more widely adopted, having python invoke python2 will remain the recommended option. The full quote is: More conservative distributions that are less willing to tolerate breakage of third party scripts continue to alias it to python2. Until the conventions described in this PEP are more widely adopted, having python invoke python2 will remain the recommended option. Correct, but since the second part isn't only restricted to conservative distribution, I didn't feel a need to quote the first part. Also, when do you suppose widely adopted will occur? If you leave space for interpretation, then expect opinions that don't match yours. This is a recommendation and someone is going to have to take the first step eventually. Here is a metaphor in the spirit of the season: Arch is the snowplow that is shoveling the snow to the sides of the road to make it easier for other distros to pass. Well, I don't care either way. As you said yourself, new programs should use python2 or python3 instead of relying on python. Considering the amount of python2 code vs python 3, Arch definitely took the more expensive approach (in terms of supporting existing python 2 code) in aliasing python to python3, while a perfectly valid approach and less burdensome and backward compatible way would have been to alias it to python2. No point in changing it now, but perhaps this could be used as a valuable lesson when python4 comes around. :) Cheers, Sander
Re: [arch-general] a plea for python 2
On 15/12/11 05:57, Angel Velásquez wrote:
On 14/12/11 19:24, Evan Martin wrote:
snip
1) Is it intentional that I am unable to use software from
upstream like Django unmodified? Am I expected to only install
software from the Arch repositories, where it has been patched by
Arch devs to work on Arch? (See below for more on Django.)
As a python developer i wonder why you don't use virtualenv [1]?
virtualenv will solve you many problems, not only in Arch, for your
development work with out-of-date or too updated python and libraries,
after do the hello world, and run the pep8 the next step for a python
developer should be to use virtualenv, in order to have best practices.
2) Should I change the software I write to attempt to detect when
I'm on an Arch system and adjust scripts/etc. accordingly? (I can't
just fix it because there is no /usr/bin/python2 on existing
systems like Macs.)
Again use virtualenvs [1] for your python development
[1] http://pypi.python.org/pypi/virtualenv
While virtualenv is by far the best approach to this if you do any kind
of serious python work, I might add that a simple $PATH trick also works
if you need something up and running *now*.
Here's the approach I used when mucking about with openembedded:
[bo@archawesome at91sam9m10-g45-ek Thu 08:25 ]$ ls python-bin/
total 0
lrwxrwxrwx 1 bo users 16 Oct 28 16:03 python - /usr/bin/python2*
[bo@archawesome at91sam9m10-g45-ek Thu 08:25 ]$ cat env.sh
#!/bin/sh
# source me.
export BBPATH=${PWD}/build:${PWD}/openembedded
# to make sure python is python2 we do this PATH hack
export PATH=${PWD}/python-bin:${PATH}
Worked well enough for that particular purpose - seeing if I could make
it run at all. If this were a real product, I'd probably lean towards
learning virtualenv sooner rather than later :)
Regards,
Bjørn Øivind
signature.asc
Description: OpenPGP digital signature
