On 10/27/2016 02:35 PM, Todd Rme wrote:
On Thu, Oct 27, 2016 at 12:51 PM, jan matejek
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.
I think there is another question hidden in here. If we make the version
number explicit in the macros, I think that is a good idea, then maybe
we should consider to do the same for the binary packages, i.e. maybe
we should drop python-foo packages and only have python2-foo and
python3-foo packages. Of course that could potentially create all kinds
of other problems but most of those could probably be addressed with a
Making the package names explicit with respect to the version would get
people used to a disassociation of the command line name and the
associated packages. Today, with the Python-2 interpreter being the
default one uses "python" on the command line and installs modules with
binary packages called "python-foo". Thus there is a nice match in
names. However, at some point in the future the "python" command will
start the Python-3 interpreter and then all of a sudden one has to
install "python3-foo" to use the module. So my thought is, if we break
this association now, while Python-2 is still the default, then the
change when Python-3 becomes the default is not going to be as traumatic
as people will already be used to not having the "python" command and
the binary package names be associated by name.
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.
I agree I don't think we should start to evict packages from d:l:p based
on some nebulous arbitrary policy decision. If an application is written
in Python it should be able to live in d:l:p. Chances are the
application provides some modules that are useful for other purposes and
the maintenance burden is reduced on the maintainer. If we evict the
application from d:l:p and make it live in d:myapp then the maintainer
of myapp has a good chance of having to back link a rather large number
of packages from d:l:p in addition to having to deal with prjconfig,
repo setup etc. which are things that are currently handled by the d:l:p
Robert Schweikert MAY THE SOURCE BE WITH YOU
Public Cloud Architect LINUX