[opensuse-factory] Heads up: Python2 / Python3 parallel installation
Hi everyone, 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. Any new Python package or update on an existing one should make sure it won't collide with it's py2 / py3 (or even pypy in the future) counterpart. That means you would want to check binaries and man-pages, they make up for 99% of file conflicts. Other candidates are desktop files, icons, ... In short, everything that doesn't install into %python_sitelib / %python_sitearch or isn't marked as %doc. If you want to get free hugs, please implement update-alternatives and consider the following packages for inspiration (in devel:languages:python): python-Sphinx, python-nose, python-pip Their counterparts live in devel:languages:python3. It that's to much effort, please assure that at least the file conflict candidates are suffixed with %py_ver, e.g. %{_bindir}/nose should become %{_bindir}/nose-%{py_ver}. For Python3 packages it's %py3_ver (I know :-). This way we can use u-a later if it becomes necessary. You can either do this by fixing entry_points=[...] in setuptools-based setup.py files (if present), fixing scripts=[...] in all setup.py files or simply by moving around binaries in %install. Thanks for your time and consideration :-) -- 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 Tue, Aug 13, 2013 at 09:43:32AM +0200, Sascha Peilicke wrote:
Hi everyone,
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. Any new Python package or update on an existing one should make sure it won't collide with it's py2 / py3 (or even pypy in the future) counterpart.
That means you would want to check binaries and man-pages, they make up for 99% of file conflicts. Other candidates are desktop files, icons, ... In short, everything that doesn't install into %python_sitelib / %python_sitearch or isn't marked as %doc.
If you want to get free hugs, please implement update-alternatives and consider the following packages for inspiration (in devel:languages:python):
python-Sphinx, python-nose, python-pip
Their counterparts live in devel:languages:python3.
It that's to much effort, please assure that at least the file conflict candidates are suffixed with %py_ver, e.g. %{_bindir}/nose should become %{_bindir}/nose-%{py_ver}. For Python3 packages it's %py3_ver (I know :-). This way we can use u-a later if it becomes necessary. You can either do this by fixing entry_points=[...] in setuptools-based setup.py files (if present), fixing scripts=[...] in all setup.py files or simply by moving around binaries in %install.
Thanks for your time and consideration :-)
Hi Sascha, great work! Can you update the packaging guidelines then? http://en.opensuse.org/openSUSE:Packaging_Python#Hints_on_how_to_Package_Pyt... Regards Michal Vyskocil
-- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
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 ;-) 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? 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? 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? Note: if you want to look at the AppArmor package, please look at it in security:apparmor (I just created a SR to factory) Regards, Christian Boltz -- Hmm.. Good point Adrian. I should get used to that thing close to my keyboard... how did you call it? Mouse? :-) [Dominique Leuenberger in opensuse-factory] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
Christian Boltz -
Michal Vyskocil -
Sascha Peilicke