On Wed, Aug 21, 2013 at 02:09:33AM -0400, Bohuslav Kabrda wrote:
----- Original Message -----
Greetings everyone, we had a productive session at flock and actually covered everything that was in my email message about a potential agenda. Here's the notes:
https://fedoraproject.org/wiki/User:Toshio/Flock2013_Python_Guidelines
Thanks for posting this, Toshio. Few comments:
- The wheel proposal seems nice, although we should probably also cover
the case where upstream _only_ distributes wheel and not tarball (shouldn't be a big deal).
I'll have to look into this a bit. I'm not certain that a wheel contains all the source. I'm almost certain that it wouldn't fit under "preferred form of modification". Depending on those, we might want to tell people tarballs, followed by source checkouts are prefered/okay. Wheels might be third on the list or might be banned as a Source: line.
- Shebang lines - So, it seems that we should both check the pip shebang
line and point %{__python} to %{__python2}, right?
Nick's idea was that pip's shebang line would be sufficient but I don't see a problem with doing both. I think that pointing %{__python} at %{__python2} will catch a few stragglers that just making sure pip is correct would not. So +1 to do both from me.
- Naming of Python modules - this section is a bit confusing for me. What
is the outcome/which way does it suggest to use? (I'm personally in favour of SRPM python-setuptools and RPMS python{2,3}-setuptools - with python2-setuptools possibly having "Provides: python-setuptools").
We decided that we'd let maintainers decide whether to ship single srpm with subpackages or multiple srpms. The implementation of subpackages was basically what you describe above. The difference in single srpm vs subpackages from the current guideline is that we'd give less direction to packagers about when to use one over the other. Currently the Guidelines say: """ The rule to choose which method [single srpm or multiple] is simple: if the python2 and python3 modules are distributed as a single tarball (many times as a single directory of source where the /usr/bin/2to3 program is used to transform the code at buildtime) then you must package them as subpackages built from a single SRPM. If they come in multiple tarballs then package them from multiple SRPMs. """
We'd change this section to say that maintainers are allowed to choose which method and then go into the sections of Pros and Cons from the current guidelines.
One thing that I've thought of -- If we're going to do another stack for pypy, how do we want to fit that in? If naming is like:
pypy2-setuptools pypy3-setuptools
Then maybe we want a separate srpm for pypy modules. Otherwise how will users know to look for python-setuptools in bugzilla.
If naming is like:
python-pypy2-setuptools python-pypy3-setuptools
The naming seems ugly and I think there's still going to be user confusion in bugzilla... So yeah -- I'm not sure if there's a naming convention for pypy modules that would make subpackages workable.
If someone can come up with a better proposal for packaging pypy modules, that might sidestep these issues.
-Toshio