A few thoughts:
1. The %python_install and %python_build macros need to be able to
support additional arguments. For example, to make a package use the
system version of a library instead of the bundled version.
2. There should be a macro to only run some commands in python 2 or
only run some commands in python 3. For example, if you need to
manually run 2to3 (not that common anymore, but needs to be
supported):
%ifpy3
2to3 -wn ./
%endif
3. Macros for %files can get complicated for packages that install
files in the root of sitelib or sitearch, since you have to deal with
__pycache__ for python 3 but not python 2.
4. What about %check? This is hard to get right with macros. There
are a variety of different ways to run unit tests. Which approach is
used varies from package to package, even amongst packages that use
the same unit testing framework. And you sometimes need to disable
some tests for one version of python or the other manualy.
5. What about packages with subpackages? matplotlib, for example, has
a ton of subpackages. Would these be created once or would they need
to be manually specified?
6. What about packages where the python and python 3 Requires are
different? For example, if a package requires a python 2 package that
backports a python 3 feature?
7. It would be really nice to have some sort of %unicode_env macro
that switches the build environment to utf8 for python packages that
need it (which is practically any package with non-pure-asciii
README).
On Thu, Sep 4, 2014 at 8:59 PM, Jan Matějek
Fellow packagers,
after some discussions in our team, we figured that it would be neat if we could build python modules for Python 2 and 3 from a single spec file. Now that a great deal of python modules work with both pythons, this makes a lot of sense.
A good deal of work can be done by RPM macros. Then we could even seamlessly start building modules for PyPy, Jython and other pythons.
A sample specfile, and the corresponding set of RPM macros, is attached. As you can see, the appropriate subpackage is generated automatically by %python_subpackages, build and install steps are handled through %python_build and %python_install respectively. There is some more magic involved, as well as possibilities for customization.
There is a minor problem with BuildRequires. As long as you only need python-devel, it's not too bad to just list $flavor-devel requirements by hand. It's worse when you require more subpackages, because then you need all of them in both python2 and python3 versions. It would be nice to be able to specify %{python_require Mako} and expand that to all the necessary BuildRequires, but OBS blocks us here, because the limited environment will not expand such macros.
mls, ro, or anyone from the OBS team, would it be possible to solve this?
Still, it basically doesn't matter if you list all the BuildRequires twice in one spec or in two specs, so there.
Another thing I'm still unclear on are the filelists. It's certainly possible to make a generic filelist, something along the lines of:
%package -n %flavor-%modname # python3-Mako %defattr(-, root, root) %{%flavor_sitelib}/* %{%flavor_sitearch}/*
but this doesn't solve docs and possible other files.
Again, obviously, we can write the filelists by hand. But if you have good suggestions for some smart macros here, I'd love to see them.
What do you folks think? Comments, questions?
m. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org