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
_______________________________________________
Fedora-python-devel-list mailing list
Fedora-python-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-python-devel-list
