On Fri, Aug 19, 2016 at 10:01 AM, jan matejek <jmatejek@suse.com> wrote:
hello folks,
as this got somehow tangled in the big python-python-* thing, I'd like to announce a working prototype of the new macroset that will let us easily build Python 2 and Python 3 packages from a single spec file.
Note that this has been possible most of the time, for anyone willing to manually write two filelists, two descriptions, two sets of requirements, etc. etc.
But with this new development, it is now possible to run a spec file through a set of small conversions and get working packages with correct dependencies (hopefully).
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 implementations out there like pypy that are becoming popular so I hink that it would be great to be able to support them down the road. So I think designing the macros now so that this support could be easily added later will make us much more flexible. 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.
The changes you need to make:
- include `%python_subpackages` macro somewhere in your specfile, preferably after the `%description` section
- convert `python setup.py build` to `%python_build` and `python setup.py install` to `%python_install`. Or copy your python2-specific build instructions and change instances of python2 to python3 (or vice versa).
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.
- convert all `BuildRequires: python-$something` to `BuildRequires: %{python_module $something}`
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 Which expands to: %if_cpy2 file %endif
- subpackages are not supported just yet. They are on the roadmap. - no automated handling of update-alternatives, but that's a whole different story
This should probably be implemented for all packages, not just Python.
- i have no idea what happens to packages that don't build with distutils/setuptools
What about a %{python_exec} macro that executes the following line in a version-specific context for each Python version?
Anyone interested can have a look at home:matejcik:messing-with-macros repository [1]. I'll probably use rest of today to fork off devel:languages:python:singlespec sub-repository and start copying packages to it. Once a critical mass of packages is there, and unless there are major objections, I'll go ahead and delete with maximum prejudice the ill-considered devel:languages:python3 repository which is a mistake that burdens us to this very day...
It would also be nice to get other distros (by which i really mean Fedora) in on this. Anyone here knows how to make that happen?
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) %have_pypy2 (defaults to 0) %have_pypy3 (defaults to 0) %have_jpy2 (defaults to 0) General tests: %if_cpy %if_cpy2 %if_cpy3 %if_pypy %if_pypy2 %if_pypy3 %if_jpy %if_jpy2 BuildRequires: %py_buildrequires %py2_buildrequires %py3_buildrequires %cpy_buildrequires %cpy2_buildrequires %cpy3_buildrequires %pypy_buildrequires %pypy2_buildrequires %pypy3_buildrequires %jpy_buildrequires %jpy2_buildrequires Requires: %py_requires %py2_requires %py3_requires %cpy_requires %cpy2_requires %cpy3_requires %pypy_requires %pypy2_requires %pypy3_requires %jpy_requires %jpy2_requires Build: %py_build %py2_build %py3_build %cpy_build %cpy2_build %cpy3_build %pypy_build %pypy2_build %pypy3_build %jpy_build %jpy2_build Install: %py_install %py2_install %py3_install %cpy_install %cpy2_install %cpy3_install %pypy_install %pypy2_install %pypy3_install %jpy_install %jpy2_install Execute an arbitrary python command %py_exec %py2_exec %py3_exec %cpy_exec %cpy2_exec %cpy3_exec %pypy_exec %pypy2_exec %pypy3_exec %jpy_exec %jpy2_exec Files: %py2_file %py3_file %cpy_file %cpy2_file %cpy3_file %pypy_file %pypy2_file %pypy3_file %jpy_file %jpy2_file Excludes/not present: %py2_exclude %py3_exclude %cpy_exclude %cpy2_exclude %cpy3_exclude %pypy_exclude %pypy2_exclude %pypy3_exclude %jpy_exclude %jpy2_exclude -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org