[arch-general] a plea for python 2
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). 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.) 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. 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. 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.) 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.) Both of those seem pretty unsatisfactory. Help! Here are some additional references, if they help you any. - Upstream Python dev believes that code that uses /usr/bin/python when it wanted Python 3 is wrong: http://mail.python.org/pipermail/python-dev/2009-April/088864.html - According to Google's Code search, there are likely around 80,000 existing Python scripts that are broken by this change. (Note that searching for /usr/bin/python[^23] doesn't work, you have to search for /usr/bin/python then subtract out the ones ending in 2 or 3: http://codesearch.google.com/#search/&q=/usr/bin/python%20lang:python&type=cs http://codesearch.google.com/#search/&q=/usr/bin/python%5B23%5D%20lang:python&type=cs ) - As a random example, here's a script from the Django project (which I chose for this mail as an example of a high-profile Python program) that uses 'python' when it means Python 2: https://code.djangoproject.com/svn/django/trunk/tests/runtests.py Here's their statement on Python 3: https://docs.djangoproject.com/en/dev/faq/install/#can-i-use-django-with-pyt... And here's the PKGBUILD, which patches around this: http://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=pa... - 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. - A Python developer discusses how Python3 is very different from Python2, making it very difficult as a developer to support both: http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/
"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/
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 <gostrc@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/
On Thu, Dec 15, 2011 at 6:54 AM, Sander Jansen <s.jansen@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).
On Wed, Dec 14, 2011 at 11:57 PM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
On Thu, Dec 15, 2011 at 6:54 AM, Sander Jansen <s.jansen@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.ht...
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
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.
On Wed, Dec 14, 2011 at 5:00 PM, Thomas Bächler <thomas@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.
On Wed, Dec 14, 2011 at 5:05 PM, Thomas Dziedzic <gostrc@gmail.com> wrote:
On Wed, Dec 14, 2011 at 5:00 PM, Thomas Bächler <thomas@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."
On Wed, Dec 14, 2011 at 5:19 PM, Sander Jansen <s.jansen@gmail.com> wrote:
On Wed, Dec 14, 2011 at 5:05 PM, Thomas Dziedzic <gostrc@gmail.com> wrote:
On Wed, Dec 14, 2011 at 5:00 PM, Thomas Bächler <thomas@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!
On 15 December 2011 07:44, Thomas Dziedzic <gostrc@gmail.com> wrote:
On Wed, Dec 14, 2011 at 5:19 PM, Sander Jansen <s.jansen@gmail.com> wrote:
On Wed, Dec 14, 2011 at 5:05 PM, Thomas Dziedzic <gostrc@gmail.com> wrote:
On Wed, Dec 14, 2011 at 5:00 PM, Thomas Bächler <thomas@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
On Wed, Dec 14, 2011 at 5:44 PM, Thomas Dziedzic <gostrc@gmail.com> wrote:
On Wed, Dec 14, 2011 at 5:19 PM, Sander Jansen <s.jansen@gmail.com> wrote:
On Wed, Dec 14, 2011 at 5:05 PM, Thomas Dziedzic <gostrc@gmail.com> wrote:
On Wed, Dec 14, 2011 at 5:00 PM, Thomas Bächler <thomas@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
On Wed, Dec 14, 2011 at 5:24 PM, Evan Martin <martine@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.
On Wed, Dec 14, 2011 at 7:53 PM, Qadri <Muhammad.A.Qadri@gmail.com> wrote:
On Wed, Dec 14, 2011 at 5:24 PM, Evan Martin <martine@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.
On Wed, Dec 14, 2011 at 08:48:25PM -0800, Evan Martin wrote:
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.
Hello. As an archer, I do not often use software which is not built with a PKGBUILD, which is an understatement. When I look for software, I first look at versions in the aur and then I look if I could package it. Next thing that comes to my informed mind, is that maybe someone did the shebang part not to our liking again. Which is really no news any more, thanks to the ongoing discussions on our mailing lists. So, thanks for the reminder, I prefer things the way they are, be they done wrong by a whole community or done "right", but overly complicated everywhere else. Wait, the latter is part of my point here, we're speaking of a text/plain fix. cheers! mar77i
-----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-----
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
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
participants (12)
-
Angel Velásquez
-
Bjørn Øivind Bjørnsen
-
David Rosenstrauch
-
Evan Martin
-
Karol Blazewicz
-
Martti Kühne
-
Oon-Ee Ng
-
Qadri
-
Ray Rashif
-
Sander Jansen
-
Thomas Bächler
-
Thomas Dziedzic