Mailinglist Archive: opensuse-packaging (102 mails)

< Previous Next >
[opensuse-packaging] Re: Some more python singlespec questions/suggestions
  • From: Todd Rme <toddrme2178@xxxxxxxxx>
  • Date: Fri, 14 Apr 2017 11:10:26 -0400
  • Message-id: <CADb7s=vP003QT2z_7k=DxYv0nGc03jjvqTreWYvfTkvEDh4uHw@mail.gmail.com>
On Thu, Apr 13, 2017 at 9:06 AM, jan matejek <jmatejek@xxxxxxxx> wrote:
On 12.4.2017 17:01, Todd Rme wrote:
Try here:
https://build.opensuse.org/package/show/home:TheBlackCat:branches:devel:languages:python/python-testtools-doc

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

You're missing this line:
%{?!python_module:%define python_module() python-%{**} python3-%{**}}
Because it's used in BuildRequires, it must be either in prjconf (in Factory)
or in the spec file.

Next time I will wait until after my 101 degree fever is over before
asking ;) Sorry.

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

If you get "inconsistent mtime" from setup.py install, it's either the
installer's or your packaging
bug. Usually you're running tests that touch things they shouldn't.

(But yes, %py_compiling it again is often easier than fixing it properly.)

I have seen it in other situations as well, and it isn't necessarily
easy to track down.

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

wouldn't "pip install" take care of it too?

Once pypi starts providing consistent URLs for wheels we can do that
when they are provided.

But even then there are packages with their own home-made build
systems that still need to be byte-compiled manually.

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
%python_version_nodots)
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.

And also easily resolvable inside the spec file.
The question here is whether this should be directly supported by a
singlespec macro.

One more point against it that it's not general: for instance, in LXML, you
run "make test" for
python2 tests and "make test3" for python3. Here you would need a variable
that is "" for python2
and "3" for python3. In other cases, you need "2" for python2 and "3" for
python3. Next time it
might be "2" for python2, "pp" for PyPy and "" for python3?

...and as long as you're if'ing it anyway, you can do this:
if [ %{$python_version_nodots} -ge 30 ]; then
mysuffix=3
else
mysuffix=2
fi

or even:
mysuffix=`expr %{$python_version_nodots} / 10`

I agree that it isn't a desirable situation, but if we want our users
to be able to use upstream documentation then we need to support
upstream naming conventions. We can create links with our own naming
patterns, but if upstream provides executable with certain names we
need to have those executables as well. And I think this is a common
enough upstream naming pattern that there should be support for it.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >