On 10/30/2009 05:11 PM, David Malcolm wrote:
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)
+1
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.
+1
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
The plan for yum is to stay with python 2.x until RHEL6 is branched and then switch to python 3.x for the yum head branch. (not writen in stone yet ) I don't think we will ever have both a python 2.x and 3.x version in the same distro, so it will fall into the previous category and can keep the name 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.
I think i should be python3-wxPython, because people seaching for wxPython will find both and can make the right choice.
Does the "purely a module" vs "is something uservisible" vs "is a stack" distinction sound sane?
Yes.
Tim