[Fedora-packaging] Proposal: naming convention for Python 3 packages and subpackages

[David Malcolm]

On Fri, 2009-10-30 at 10:28 +0100, Tim Lauridsen wrote:
> On 10/30/2009 09:57 AM, Tim Lauridsen wrote:
> > On 10/30/2009 01:15 AM, David Malcolm wrote:
> >> On Thu, 2009-10-29 at 18:42 -0400, John Dennis wrote:
> >>> On 10/29/2009 06:27 PM, David Malcolm wrote:
> >>>
> >>>> I rather like the idea of standardizing on a "python3-" prefix for
> >>>> _all_
> >>>> Python 3 module packages and subpackages, even if this leads to
> >>>> inconsistencies with their counterparts in the python 2 stack. It would
> >>>> make the "threeness" of the packages stand out more.
> >>>>
> >>>> Thoughts?
> >>>
> >
> > for the
> >
> > python-<package> -> python3-<package>
> > py<package> -> python3-py<package> (I think we should keep the py to
> > make it easier to locate stuff pygpgme)
> > <package>-python -> python3-<package>
> >
> > Seem good to me.
> >
> > But there is a lot of packages installing stuff into
> > /usr/lib/pythonX-Y/site-packages there don't fit 3 cases.
> >
> > Ex. yum
> >
> > It is an application, but also an python API used by other packages, how
> > do we handle there cases.
> >
> > I have attacted the the sorted output from
> >
> > repoquery -f '/usr/lib/python2.6/site-packages/*'
> >
> > Tim
> >
> 
> I have added a ordered file categorizing the packages in
> 
Very nice, thanks!

In my email I said "Python 3 module packages and subpackages", and I'm
not being very precise about this.

Can a distinction can be drawn between an rpm that "merely" packages a
python module?   I think that many of our rpms have payloads that are
entirely below:
  /usr/lib/python2.6/site-packages
  /usr/share/doc/NAME-VERSION
I suspect that most of the packages within these lists fall into this
category:
  "Packages starting with 'python-':"
  "Packages starting with 'Py' or 'py' (but not 'python-')"
  "Packages ending with '-python':" (most of these seem to be
subpackages from a mostly non-python build)


Contrast this with the "None of the above:" category.  At a quick look,
most of the packages in this list appear to be using python as an
implementation detail, in order to get some user-facing job done.  For
these, I feel we'd port them one-by-one, and the name need not change.

A complication/exception in this last category is for plugin systems and
"stacks".  For example, yum and its various plugins/extensions don't
mention python in their name, but they're written in python 2.
Similarly, Django and the various django-foo packages implement the
Django web development framework, which happens to be written in python
2 (hopefully will eventually have python 3 support), and "trac-foo".  My
gut feeling for both of these cases is that we'd want python 2 and 3
versions for a while, so perhaps a python3- prefix is ok.  That would
give us e.g.:
python3-trac-privateticketsplugin
python3-TurboGears
python3-TurboGears2
python3-yum

I noticed "wxPython" in the "none of the above" naming bucket.  This one
definitely feels like a support module, rather than a thing to be used
in its own right (python bindings to the wxWidgets library).
  - wxPython3 ?
  - python3-wx ?
etc  not sure; maybe depends on upstream.

Does the "purely a module" vs "is something uservisible" vs "is a stack"
distinction sound sane?

Dave