On 10.4.2017 17:09, Todd Rme wrote:
A few questions and ideas have popped up for me while doing the singlespec conversion:
First, is there a way to use the macros without actually setting up the multiple packages? Particularly I need to use %{python_module foo}, but %python_expand and %python_exec would also be useful. The main use-case is for packages where the unit tests have been moved into a separate -doc spec file to avoid dependency cycles. These packages need to import both python2 and python3 dependencies to for the unit tests, and ideally would use %python_expand or %python_exec to run the tests. But the documentation itself would only be built once, so we don't need multiple rpms. I tried %_python_macro_init but it didn't work.
AFAIK the macros you list work fine by themselves. (of course, you still need to require python-rpm-macros; and if you are using %python_module in BuildRequires, you still need to shim the definition) If you're seeing failures, show me :) The only macros whose presence depend on each other are %python_subpackages and %python_files. Either will cause an error if the other is not used.
Second, is there a single-spec version of %py(3)_compile? Ideally it would be nice to have %python2_compile and %python3_compile that could be used with %python_expand, as well as a macro that automatically run them both on %{buildroot}%{python(2/3)_sitelib} and %{buildroot}%{python(2/3)_sitearch} (whichever exists).
Not as of now; so far the singlespec macros were geared towards setuptools-based installations where you don't use %py_compile. We can add it.
Third, is there a macros to get just the current python major version number? So "2" for python2 and "3" for python3? So projects, such as the jupyter suite, use a "foo2-bar"/"foo3-bar" pattern that we need to support, so having a macro to get the major number is pretty critical especially since IPython is dropping python2 support soon so we need to be able to adjust the build targets easily.
what will happen to such packages when they encounter pypy3? 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?
Third, the wiki recommends defining %oldpython when you need a specific python-foo dependency. Considering how often the backports are used these days in python2 packages, might this be a macro that would be good to include so people don't have to manually define it?
If a backport doesn't provide python2-name, it's a bug and should be fixed. As for adding %oldpython to the macro set for other cases (obsoletes/provides usually), maybe? (Or maybe find a different spelling; %oldpython is good because it is easy to fit it into any spec file, but it is a hack. Something like "Provides: %{literally python-foo}" would be nicer)
Fourth, I notice the python2-foo versions of the packages (for Tumbleweed) provide python-foo, but the python-foo versions (for older releases) do not provide python2-foo. For maximum simplicity and compatibility, might it be good to have the python-foo versions also provide python2-foo?
Not as easy as it looks, unfortunately .e( I can add auto-provides to the main package, but I can't touch subpackages. That way the "maximum simplicity and compatibility" is a half-promise. However it seems that practicality does beat purity here, as most packages don't have subpackages anyway, so I guess i'll put it on my TODO list. regards m.