On 10/27/2016 02:35 PM, Todd Rme wrote:
On Thu, Oct 27, 2016 at 12:51 PM, jan matejek <jmatejek@suse.com> wrote:
hello packagers,
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 [1] and the github repo [2] 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_pypy2" 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 few scripts. 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 policy proposal:
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 approach?
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 dlp"?
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 project maintainers. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo