On Thu, Dec 15, 2011 at 6:54 AM, Sander Jansen 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 5:00 PM, Thomas Bächler 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:19 PM, Sander Jansen wrote:

On Wed, Dec 14, 2011 at 5:05 PM, Thomas Dziedzic wrote:

...

On Wed, Dec 14, 2011 at 5:00 PM, Thomas Bächler 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 Wed, Dec 14, 2011 at 5:44 PM, Thomas Dziedzic wrote:

On Wed, Dec 14, 2011 at 5:19 PM, Sander Jansen wrote:

...

On Wed, Dec 14, 2011 at 5:05 PM, Thomas Dziedzic wrote:

...

On Wed, Dec 14, 2011 at 5:00 PM, Thomas Bächler 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 7:53 PM, Qadri wrote:

On Wed, Dec 14, 2011 at 5:24 PM, Evan Martin 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.