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