Mailinglist Archive: opensuse-packaging (102 mails)

< Previous Next >
[opensuse-packaging] Re: Some more python singlespec questions/suggestions
On 10.4.2017 17:09, Todd Rme wrote:
A few questions and ideas have popped up for me while doing the
singlespec conversion:

First, is there a way to use the macros without actually setting up
the multiple packages? Particularly I need to use %{python_module
foo}, but %python_expand and %python_exec would also be useful. The
main use-case is for packages where the unit tests have been moved
into a separate -doc spec file to avoid dependency cycles. These
packages need to import both python2 and python3 dependencies to for
the unit tests, and ideally would use %python_expand or %python_exec
to run the tests. But the documentation itself would only be built
once, so we don't need multiple rpms. I tried %_python_macro_init but
it didn't work.

AFAIK the macros you list work fine by themselves.
(of course, you still need to require python-rpm-macros; and if you are using
%python_module in
BuildRequires, you still need to shim the definition)
If you're seeing failures, show me :)

The only macros whose presence depend on each other are %python_subpackages and
Either will cause an error if the other is not used.

Second, is there a single-spec version of %py(3)_compile? Ideally it
would be nice to have %python2_compile and %python3_compile that could
be used with %python_expand, as well as a macro that automatically run
them both on %{buildroot}%{python(2/3)_sitelib} and
%{buildroot}%{python(2/3)_sitearch} (whichever exists).

Not as of now; so far the singlespec macros were geared towards
setuptools-based installations where
you don't use %py_compile.
We can add it.

Third, is there a macros to get just the current python major version
number? So "2" for python2 and "3" for python3? So projects, such as
the jupyter suite, use a "foo2-bar"/"foo3-bar" pattern that we need to
support, so having a macro to get the major number is pretty critical
especially since IPython is dropping python2 support soon so we need
to be able to adjust the build targets easily.

what will happen to such packages when they encounter pypy3?

In any case I'm not convinced that this should be a part of the "singlespec
API". Basing decision on
"major version of python", as opposed to "is this python2 or something newer",
does not look like a
good practice.
(and if it's limited to one package, you can easily get, e.g. from
OTOH, maybe this distinction will be useful again with Python 4 somewhere down
the road, so perhaps?

Third, the wiki recommends defining %oldpython when you need a
specific python-foo dependency. Considering how often the backports
are used these days in python2 packages, might this be a macro that
would be good to include so people don't have to manually define it?

If a backport doesn't provide python2-name, it's a bug and should be fixed.

As for adding %oldpython to the macro set for other cases (obsoletes/provides
usually), maybe?
(Or maybe find a different spelling; %oldpython is good because it is easy to
fit it into any spec
file, but it is a hack. Something like "Provides: %{literally python-foo}"
would be nicer)

Fourth, I notice the python2-foo versions of the packages (for
Tumbleweed) provide python-foo, but the python-foo versions (for older
releases) do not provide python2-foo. For maximum simplicity and
compatibility, might it be good to have the python-foo versions also
provide python2-foo?

Not as easy as it looks, unfortunately .e( I can add auto-provides to the main
package, but I can't
touch subpackages. That way the "maximum simplicity and compatibility" is a
However it seems that practicality does beat purity here, as most packages
don't have subpackages
anyway, so I guess i'll put it on my TODO list.


< Previous Next >
Follow Ups