On 08/15/2013 02:16 PM, Christian Boltz wrote:

Hello,

Am Dienstag, 13. August 2013 schrieb Sascha Peilicke:

...

the next openSUSE release will have very strong support for Python3 and I've been working a lot on improving parallel installation of Python2 / Python3 modules. In other words, the most important packages (virtualenv, pip, nose, coverage, Sphinx, ...) now use update-alternatives.

Are there plans to make the /usr/bin/python symlink managed with update- alternatives? If yes, this will open an interesting can of worms ;-)

I'm a bit surprised this isn't the case already. When looking at the mess in /usr/bin, I'm close to puking into the next trashcan. Who is supposed to manage all these links by hand? /usr/bin/python -> python2.7 /usr/bin/python2 -> python2.7 /usr/bin/python2.7 /usr/bin/python2.7-config /usr/bin/python2-config -> python2.7-config /usr/bin/python3 -> python3.3 /usr/bin/python3.3 /usr/bin/python3.3-config -> python3.3m-config /usr/bin/python3.3m /usr/bin/python3.3m-config /usr/bin/python3-config -> python3.3-config /usr/bin/python-config -> python2-config So I'm gonna fix this ASAP :-)

Let me use the AppArmor package as an example. It has some scripts with #!/usr/bin/python - but they are all py2 and py3 compatible.

The devil is in the detail - for example aa-easyprof uses a python module that is currently packaged in the py2 directories - so in theory aa-easyprof works with py3, but in practise it won't find the python module ;-)

What is the recommended way to handle such things?

Repackage for Python3, it's a different ABI.

Another question: I'm going to enable the libapparmor python bindings, which are needed for the new logprof etc. currently developed in GSoC.

At the moment I can build the py2 _or_ the py3 bindings in the package, but not both at the same time. Is it worth the effort to build for both python versions, or should I just build the py3 bindings only and get a #!/usr/bin/python3 in the upcoming new logprof?

Whatever you think is best. Currently, we're opting for the "both will co-exist for the years to come" solution. Pretending everyone will jump on Python3 just now isn't realistic to me. But it is perfectly valid (and helping in the long run) if upstreams decide to move to Py3. Py3 will be part of SLE_12, so you won't have any issues there. But there's still SLE_11_SP3, RHEL_6 and Debian... IMO the easiest option now is to make sure, your Py2 code works with 2to3. On the other hand, there are plenty of good guides out there for supporting both versions with one codebase. The six module also helps.

To make the question more interesting: To get more testers for the new logprof etc., I'd like to add/enable the python bindings with the next AppArmor update for 12.2 and 12.3. Is py3-only also ok there?

As said, whatever works best for you. Several distro tools have been ported to Py3 already. Only rpmlint is missing ATM but that's a non-issue.

Note: if you want to look at the AppArmor package, please look at it in security:apparmor (I just created a SR to factory)

-- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

On 08/15/2013 03:47 PM, Claudio Freire wrote:

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

...

On 08/15/2013 02:16 PM, Christian Boltz wrote:

...

Hello,

Am Dienstag, 13. August 2013 schrieb Sascha Peilicke:

...

the next openSUSE release will have very strong support for Python3 and I've been working a lot on improving parallel installation of Python2 / Python3 modules. In other words, the most important packages (virtualenv, pip, nose, coverage, Sphinx, ...) now use update-alternatives.

Are there plans to make the /usr/bin/python symlink managed with update- alternatives? If yes, this will open an interesting can of worms ;-)

I'm a bit surprised this isn't the case already. When looking at the mess in /usr/bin, I'm close to puking into the next trashcan. Who is supposed to manage all these links by hand?

/usr/bin/python -> python2.7 /usr/bin/python2 -> python2.7 /usr/bin/python2.7 /usr/bin/python2.7-config /usr/bin/python2-config -> python2.7-config /usr/bin/python3 -> python3.3 /usr/bin/python3.3 /usr/bin/python3.3-config -> python3.3m-config /usr/bin/python3.3m /usr/bin/python3.3m-config /usr/bin/python3-config -> python3.3-config /usr/bin/python-config -> python2-config

So I'm gonna fix this ASAP :-)

This is upstream

Just configure, make make install will do that from a pristing tarball.

So? In fact, upstream cares about parallel-installability of different ABI versions or even Interpreter implementations, take PEP-3147 as an example. However, they don't know the mechanism all the various distros are going to apply. Thus they're installing a default /usr/bin/python binary which is not suffixed to not break everything. See below.

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. Let me step back a bit from technical details. At some point we have to make Python3 the default. Some bumps are expected while doing so. Now is the right time to do it.

We could use update alternatives for nose and other python scripts, ...

We are already doing for most core packages already. It's unavoidable if you need to work with both major versions. Yes you can use virtualenv to achieve similar things, but we're a distro, no? -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

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 :-) -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

On Fri, Aug 16, 2013 at 06:18:36PM -0300, Claudio Freire wrote:

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

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

Hello, Am Donnerstag, 15. August 2013 schrieb Sascha Peilicke:

On 08/15/2013 03:47 PM, Claudio Freire wrote:

...

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

...

On 08/15/2013 02:16 PM, Christian Boltz wrote:

...

...

...

Are there plans to make the /usr/bin/python symlink managed with update- alternatives? If yes, this will open an interesting can of worms ;-)>> I'm a bit surprised this isn't the case already.

...

...

So I'm gonna fix this ASAP :-)

I'm not sure if this is a good idea, see below for details.

...

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.

Let me explain what I meant with "interesting can of worms" ;-) The biggest "worm" are dependencies: Assume a package currently comes with Requires: python-whatever because a python script in this package contains import whatever For python3, you'll instead need Requires: python3-whatever (Of course, py2 won't find installed py3 modules, and py3 won't find installed py2 modules because they are installed in different paths.) Now tell me which Requires: line I have to write in the spec when the user can easily change the python version behind my back (and without telling the package manager)... Hint: the only guaranteed working option is to add py2 _and_ py3 requires, but I doubt this is what we want ;-)

Let me step back a bit from technical details. At some point we have to make Python3 the default. Some bumps are expected while doing so. Now is the right time to do it.

I'd say the dependencies are a quite big bump ;-) BTW: for AppArmor, I think I have a decision: I'll create only py3 packages for the libapparmor bindings. Well, there's an exception: for 12.2, I have to create a py2 package because swig is broken for py3 there [1] and I somehow ;-) doubt someone wants to fix swig on 12.2 (tell me if I'm wrong ;-) Regards, Christian Boltz [1] probably http://sourceforge.net/p/swig/bugs/1257/ -- Die Signatur will nicht angezeigt werden. Die gewuenschte Signatur ist zur Zeit nicht verfuegbar. Moeglicherweise ist sie gerade im Urlaub oder hat einfach keine Lust angezeigt zu werden. Oder wollen Sie staendig beobachtet werden? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org