[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:       Todd Rme <toddrme2178 () gmail ! com>
Date:       2017-11-15 15:45:20
Message-ID: CADb7s=sZ0zN_xc_iW4SrtWVkyUggJqFBzn_7ZjM5TZJE8GaiQg () mail ! gmail ! com
[Download RAW message or body]

On Wed, Nov 15, 2017 at 9:43 AM, jan matejek <jmatejek@suse.com> wrote:
> 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 different 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.

It is pretty common for tests.

>> 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 empty string in place of
> %python2_module. We'd need to have something like %python2_buildrequires, but that sounds too
> specific and impractical.

Would it be possible to replace disabled requires with some dummy
package that is a buildrequires by default anyway?


>> 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 move this directory around to
> "_build.$flavor", so that python is not reusing pycs from the wrong version. 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.)

Can the macros move "_build.$flavor" to "build" during the
corresponding part of "python_expand"?
-- 
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]