[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse-packaging
Subject:    [opensuse-packaging] Re: Some more python singlespec questions/suggestions
From:       Todd Rme <toddrme2178 () gmail ! com>
Date:       2017-04-14 15:10:26
Message-ID: CADb7s=vP003QT2z_7k=DxYv0nGc03jjvqTreWYvfTkvEDh4uHw () mail ! gmail ! com
[Download RAW message or body]

On Thu, Apr 13, 2017 at 9:06 AM, jan matejek <jmatejek@suse.com> 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@opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org


[prev in list] [next in list] [prev in thread] [next in thread]