Notes from the python guidelines discussion at flock

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/python-devel/attachments/20130821/9b9a217c/attachment.sig>