Re: [opensuse-packaging] Re: [opensuse-factory] Heads up: Python2 / Python3 parallel installation

On Fri, Aug 16, 2013 at 5:04 AM, Sascha Peilicke wrote:

On 08/15/2013 07:51 PM, Claudio Freire wrote:

...

On Thu, Aug 15, 2013 at 11:17 AM, Sascha Peilicke wrote:

...

...

In fact, I'm not a big fan of using alternatives. Both versions aren't so easily switchable. I happen to agree with the can of worms thing.

The only thing needing u-a is the /usr/bin/python binary (and probably the man-page). Of course we ship a lot of Python software with she-banks like "#!/usr/bin/python" or "#!/usr/bin/env" python. Whenever one of those just accepts one specific major version, it needs adjustment.

So I would like to u-a the "python" and "python3" package with the latter having a higher priority (thus being the default). Software that insists on the old Python-2.7 can be fixed to use #!/usr/bin/python2 instead. On the other hand, most upstream codebases actually run on both, so it's not going to be a big issue.

Yes, that's the issue I mention. Lots of software wrongfully requests "any python" when in fact they require python2.

And in any case, it's not like the user really should be able to switch our packages (the ones that do accept any python version) between py2 and py3 at will. That will create a support nightmare. The packager should be the only one deciding.

Ok, as replied to Christian already, I agree it's probably better to stay with the current solution. Let's wait and see what people expect /usr/bin/python to be in the future :-)

I saw it. On the other hand, your point about pypy is compelling. Having a distribution-provided pypy translation as default python version would be very interesting and valuable (because of the relatively high resources it requires to translate pypy itself), but perhaps pypy itself isn't up to that task yet (having tons of important extension modules that cannot be supported without jumping through big hoops). If pypy was a reasonably compatible replacement, I'd reconsider moving towards u-a I think pypy needs a way to provide the equivalent of python C extensions in a distribution-friendly way to get there. Currently, the only (good) way to provide them, is by including an R-Python implementation during interpreter translation. That's completely opposite to package management. cpyext can't be considered, it's not "native" to pypy and its performance will never compare to R-Python implementations. Ok, I digressed a bit towards pypy, but you raised a very interesting point I should say. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org