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)