On Mon, Aug 22, 2016 at 9:23 AM, jan matejek <jmatejek@suse.com> wrote:
hello,
On 19.8.2016 18:41, Todd Rme wrote:
One thing I think that would be really important is that we support more than just Python 2 and Python 3. There are other python
that is what i'm trying to do, yes.
So I think rather than having this in terms of "python2" and "python3", we should use something like "cpy2", "cpy3", "pypy2", "pypy3", "jpy2", etc. format for macros. So for example "%have_cpy2", "%have_pyp3", etc. There could also be shortcuts for packages that only support python versions or implementions, so example "py2" would match any python 2 implemention, or "pypy" would match any version of pypy, and just "py" would match any python. These patterns would be followed in every macro, so once you know that pattern you know how to use every macro.
It is reasonable to have "if_cpython2" etc., but for all the rest, I'd much rather have a common set of python_* macros that would take on the meaning of whatever is currently necessary -- regardless of which python(s) is/are used to build the package.
The idea would be to have common macros, as well as more specific macros for special cases.
But I think that we will see how much specificity is actually needed.
What about unit tests? I could see either just doing it manually using %if_foo commands, executing an arbitrary python command for each python version, allowing packages to provide their own macros, or tying into update-alternatives somewhow.
at the moment my plan is to do this manually with %if_foo, or alternately through something like %{py_exec_all nosetests} using the %py_exec machinery you proposed.
Limitations: - filelists must be the same. I have not figured out a way to make this work otherwise, except maybe by forcing the packager to write out both (all) %files sections by hand, which doesn't seem satisfactory.
What about having, for example:
%{cpy2_file} file
Unfortunately, i could not manage to write a macro that would work like this. Best I could do was %{cpy2_file file} and there were some unresolved problems too.
Which expands to:
%if_cpy2 file %endif
Which I now figured out how to generate and write, so this is going to be the preferred syntax, unless someone steps up as a better RPM macro writer than I am ;)
What about a %{python_exec} macro that executes the following line in a version-specific context for each Python version?
I like this idea. I'll see what I can do about making it work. ISTM you basically only need to substitute the correct executable? Possibly mess with what "env python" returns, but OTOH perhaps we should run the scripts with an explicit interpreter, and consider "env python" a bug... which we've been quietly doing since forever.
So here are the macros I was thinking about. (of course pypy and jpy are not supported now, that is just the format they would take if any when they are supported down the road.).
Specify which python versions to build: %have_cpy2 (defaults to 1) %have_cpy3 (defaults to 1)
yes, although i'd call them full "cpython"
I was trying to keep things concise and consistent. Having %buildrequires_cpython3 would mess up the alignment currently being used in spec files.
%have_pypy2 (defaults to 0) %have_pypy3 (defaults to 0)
I don't think introducing "pypy2" support now is a good idea. Given that pypy is not established, I say we go ahead and only support the Python3 variant.
I am not suggesting we support it now, just that this is the pattern it would take once it is supported. That being said, it is pretty popular and quite a few python packages already explicitly list support for it.
General tests: %if_cpy %if_cpy2 %if_cpy3
I don't see the usecase of testing for both "cpython-any" and "cpython-particular". Why would we ever want that?
Because some dependencies or actions will be needed for cpython variants but not, for example, pypi variants, or vice versus. Easier to have one macro that can be used rather than writing everything twice.
Also there is an interesting technical dilemma with this syntax: either %if_cpython2 means "if cpython2 is in the buildset", or "if the following piece of code applies to the cpython2 subpackage". These are very different in the requires/filelist context:
This was intended for the latter case. I can't think of a situation where it would be useful for one python variant to know that some other python variant is also being built. I thought the whole idea was to keep them separate.
BuildRequires: %py_buildrequires
With my current approach this doesn't seem useful at all? Either you use %{python_module foo} to get module for all pythons that are in %have_flavor, or you can list the buildrequires explicitly.
Some buildrequires are only relevant, or only available, for certain python variants. So there needs to be some way to specify buildrequires on a per-variant basis. You could wrap them in an %if_foo clause, but that seems much more verbose to me.
Build: %py_build (...)
Install: %py_install (...)
Why would we need this? instead of "python setup.py build", but for particular pythons? That doesn't seem practical IMHO, better to have "%python_build" that builds all, or "%cpy3_exec setup.py build" if you need specific instructions?
This would essentially be a shortcut of the latter. I guess it isn't entirely necessary. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org