On Fri, Aug 16, 2013 at 06:18:36PM -0300, Claudio Freire wrote:
On Fri, Aug 16, 2013 at 5:04 AM, Sascha Peilicke <speilicke@suse.com> wrote:
On 08/15/2013 07:51 PM, Claudio Freire wrote:
On Thu, Aug 15, 2013 at 11:17 AM, Sascha Peilicke <speilicke@suse.com> 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
http://software.opensuse.org/package/pypy Which reminds me - maybe it should stop install /usr/bin/pypy right now as pypy3 have reached beta status.
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.
I would not say rpython is usefull to anything that to write an interpreter/JIT for some language. However the Python C API compatibility is an issue for pypy (as well as for any other alternative implementation). Actually there are two reasonable ways for native modules - ctypes or cffi. The first one is in standard library, the later one is supported and developed by pypy devs and should fill the gap between alternative Python implementations and native modules. And of course, cffi is much easier to use than all other alternatives including ctypes, cython or raw C API. Regards Michal Vyskocil
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