On Thu, Oct 27, 2016 at 12:51 PM, jan matejek <jmatejek(a)suse.com> wrote:
i'm happy to announce that i have a macroset that works pretty well, if
i say so myself :)
Have a look at the d:l:python:singlespec repository  and the github
repo  for details.
The gist of it: it is now very possible to build packages for both
python 2 and python 3, using a pretty straightforward set of macros. See
spec files in the linked repository, and documentation on github.
So far this only reliably works on python 2 and 3. It can work with pypy
too, but pypy is not building so I can't test against it.
Some comments on the macros:
1. I think the version number should be explicit in all cases. So it
should be "%have_python2", not "%have_python", and
"%have_pyp3", not "%have_pypy".
2. Along those lines, I think pypy2 and pyp3 versions should be
available, especially with a lot of progress now happening in pypy3
thanks to mozilla funding it.
4. New policies for d:l:py
If the transition goes smoothly, I'd like to use the opportunity to
clean out the devel:languages:python project.
One, d:l:py is collecting applications that happen to be *written in*
Python, but have nothing to do with python development, and should
instead be placed in other topically appropriate projects. We've had
some discussions about dependencies only present in d:l:py, but here's a
When was this ever not the case? There are packages like that which
haven't been updated in 4 or 5 years. I did some spot checks and the
other devel:languages:___ repos also have a wide variety of software
written in that language. What do you see as wrong with the current
If your package depends on d:l:py and is not
appropriate for d:l:py, you
can either push your dependencies to Factory, or link them to your
topically appropriate project.
I think you are fundamentally changing the purpose of dlp here. So I
think the first thing we need to decide is "what is appropriate for
I would personally keep dlp as a generic place for all python
packages. This has worked very well up to this point and I don't see
any advantage to changing it.
Two, end-user applications should start to move to
Python 3. This is
already happening. The relevance here is that we can now build
"dual-version" packages. This should be discouraged. There are packages
where that is appropriate (pip, nose and similar), but most packages
should only provide executables for python3. We have a great number of
packages that act as modules (= dependencies for other packages) and
also as command-line utilities.
Policy proposal: Unless we actually need the executable for all versions
of python, all executables should be %py3_only.
I think the rule should be that if the executable is intended for use
with python files or packages, it should provide both python 2 and
python 3 versions when available. So this would include installers
like pip, analysis and testing tools like pylint and pytest, IDEs like
spyder and eric, and shells like bpython and ipython. It would not
include general-purpose tools that happen to be written in Python like
the python wget implementation.
Also, in the case if bindings, when a package only supports building
bindings for one python version, the (c)python 3 version should be
Finally, three, d:l:py is collecting non-python
dependencies of python
modules. That should not be happening. Analogously to point one, policy
proposal: If your package depends on something that is not appropriate
for d:l:py, either get that dependency into Factory, or your package is
also not appropriate for d:l:py.
A lot of these are backports for older versions of openSUSE that
either have outdated versions of the library or lack the library
entirely. So yes, I agree if it really has non-Factory dependencies
it probably shouldn't be there. But I think the bigger problem is
that many of these are (or were) needed but are building for openSUSE
versions where they aren't really needed, or where the version they
were needed for is no longer supported. A cleanup of these is
certainly warranted. They should also probably be renamed (package,
not .spec file) to include the version of openSUSE they are needed for
so we can clean them up more easily later.
5. Naming scheme
Finally some bikeshedding: names of RPM macros for python-related things
are inconsistent. We have %py_ver and %py_compile and %python_sitelib
and %ifpython2 and %py2_only.
I would like to keep "python" and "py" as *generic* versions of the
macros, not specifically referring to a particular version or flavor of
Python. So for every "py_" and "python_", equivalent "py2_"
"python2_" should be defined.
This is partially true in the new macro set already.
As I said above, I think the exceptions should be fixed in the macros
before we start using them. It will be much harder to change the
Another thing is with "short" and
"long" versions. I would really prefer
to use only one of them, and that's probably the short one. Keep %py_ver
and %py2_ver, but make %py2_sitelib etc.
The last thing is about executables for pypy. For
installing pip for python2 and python3, you get pip-2.7 and pip-3.5.
What should the pypy variant be called?
Probably pip-pp2.7 and pip-pp3.5. Jython would be pip-jp2.7 if we
ever got around to supporting it.
Some additional issues:
1. The layout of the repositories. With single spec files, does
"devel:languages:python3" even make sense anymore? I think we should
phase it out.
2. Package naming. Might this be a chance to switch from using
python-foo to python2-foo? Either way, I would strongly suggest pypy
packages using pypy2-foo and pypy3-foo from the beginning, rather than
3. Version-specific packages. There are still a lot of packages that
only support python 2, and an increasing number that only support
python 3. Should these use the macros or be kept simple?
4. Repository cleanup. There are packages that haven't been updated in
many years and are not under active development. Who knows what sort
of security or compatibility issues they might have. It might be
worthwhile to move them to a separate repository (perhaps
d:l:p:archive or d:l:p:legacy) with lower build priority, or delete
them outright, to free up resources for packages that are
5. Disabled packages. Packages that are completely disabled should
almost certainly be deleted.
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org