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

List:       opensuse-packaging
Subject:    [opensuse-packaging] Re: New thoughts on python singlespec macros
From:       jan matejek <jmatejek () suse ! com>
Date:       2017-11-15 14:43:32
Message-ID: eba8c125-789d-f3f6-7f99-78c50a0b7d45 () suse ! com
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


hello,

On 14.11.2017 19:29, Todd Rme wrote:
> Regarding 1, there are currently two pain points. First and most
> obvious is the fact that the shebangs have to be edit manually.  The
> second is that if we want versioned shebangs, we need to manually
> recompile the files to avoid mtime issues.

The second is sort of a "wrong point". Files that need shebangs are diffe=
rent from files that need
bytecode. Scripts that you directly execute don't create pyc files.
Of course, some upstreams put shebangs everywhere, and in rare cases you =
get a file that is both a
module (gets a pyc when used by others) and an executable.

But in general i wouldn't want to bend over backwards for this.

> Ideally changing the shebangs could be handled automatically during
> %python_build,

It is for files declared as executables. Distutils / setuptools do that.

> but there could still be a separate macro that could be
> called in cases where manual changes are necessary.  Recompiling is
> needed in other situations as well, so having a macro to handle that
> would be useful in general.

yes, we need $flavor_compile. I've had some blocking issues with it, i do=
n't recall what they were...

Also yes, we need the shebang macros. I'll just, uh, go ahead and put the=
m in python-rpm-macros.

> Regarding 3, there are again two main pain points. The first is that
> there is no macro I am aware of to reliable determine if a given
> python version is being built.  %have_python2 and %have_python3 no
> longer work reliably AFAIK.

Never worked in the first place ;) But yes.
I've been setting %bcond_without python2, then wrapping python2 parts in =
%if %{with python2}, same
for other flavors if necessary. This works even for buildrequires.
This is a possibly good convention. I'll look into if we can do the %with=
 part without explicitly
setting the bcond in every package.

> python2 builds are disabled.  Ideally I would like to see
> "%{python2_module foo}" and "%{python3_module foo}" that will only
> pull in that dependency if that version of python is being used.  This
> also has the advantage of not needing to care about
> backwards-compatibility issues of "python-foo" vs. "python2-foo"
> names, which is handled inconsistently right now.  If that is not
> feasible, just having a reliable check would be an improvement.

The issue with "BuildRequires: %python2_module" is that you can't put emp=
ty string in place of
%python2_module. We'd need to have something like %python2_buildrequires,=
 but that sounds too
specific and impractical.
Having a reliable guard conditions, like the %with thing, is probably a b=
etter way.

> Regarding 4, I don't really understand what "%python_expand" is doing
> behind the scenes, and whether there is a simple workaround or whether
> the macro needs to do something different internally.

I suspect this might be better fixed by a patch to pytest....

(setuptools create a "build" directory and all python_expanding macros mo=
ve this directory around to
"_build.$flavor", so that python is not reusing pycs from the wrong versi=
on. This should not be
necessary in theory, but in practice it is. pytest knows to ignore "build=
" directory, but doesn't
know about "_build". Probably easiest to teach pytest about its existence=
=2E)


["signature.asc" (application/pgp-signature)]
-- 
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]