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.
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 don't recall what they were... Also yes, we need the shebang macros. I'll just, uh, go ahead and put them 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 empty 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 better 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 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.)