Mailinglist Archive: opensuse-packaging (102 mails)

< Previous Next >
[opensuse-packaging] Re: Some more python singlespec questions/suggestions
  • From: Todd Rme <toddrme2178@xxxxxxxxx>
  • Date: Wed, 12 Apr 2017 11:01:10 -0400
  • Message-id: <>
On Wed, Apr 12, 2017 at 8:39 AM, jan matejek <jmatejek@xxxxxxxx> wrote:
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 :)

Try here:

I get errors like this outside Tumbleweed: "nothing provides
%{python_module, nothing provides testtools = %{version}}"

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.

Even in setuptools, you sometimes need to run %py_compile due to, for
example, "inconsistent mtime" rpmlint warnings.

But more and more packages are shipping wheels only, so having support
for %py_compile, and less importantly "pip install", is becoming

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?

No idea, that is up to the upstream project to decide.

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?

I agree with you, but this is an upstream decision.

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)

I think that whatever is recommended on the wiki should be supported
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups