From tim.lauridsen at googlemail.com Mon Nov 2 06:03:58 2009 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Mon, 02 Nov 2009 07:03:58 +0100 Subject: [Fedora-packaging] Proposal: naming convention for Python 3 packages and subpackages In-Reply-To: <1256919073.10194.102.camel@brick> References: <1254417309.9551.34.camel@radiator.bos.redhat.com> <4AC50044.6090804@gmail.com> <1256855255.3731.3394.camel@brick> <4AEA1A6B.10601@redhat.com> <1256861701.3731.3552.camel@brick> <4AEAAA5E.4040501@googlemail.com> <4AEAB1BD.8050606@googlemail.com> <1256919073.10194.102.camel@brick> Message-ID: <4AEE764E.4050401@googlemail.com> 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- -> python3- >>> py -> python3-py (I think we should keep the py to >>> make it easier to locate stuff pygpgme) >>> -python -> python3- >>> >>> 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 From dmalcolm at redhat.com Wed Nov 11 00:13:25 2009 From: dmalcolm at redhat.com (David Malcolm) Date: Tue, 10 Nov 2009 19:13:25 -0500 Subject: Python 3 packaging Message-ID: <1257898405.8419.312.camel@brick> I'm working on a python 3 stack for Fedora 13, parallel-installable with the default python 2 stack [1] I've attempted to package python 3, and package some python modules for python 3. So far, I've got a "python3-rpm", a "python3-lxml", and two different ways of packaging "python3-setuptools", though none of these are actually in our CVS yet [2]. Thanks everyone for your help so far. In doing so, I've been writing some proposals on packaging guidelines for Python 3 - both for secondary python runtimes, and for modules for them. You can see what I've written so far here: https://fedoraproject.org/wiki/PackagingDrafts/Python3 Obviously this is a work in progress but hopefully makes sense as far as it goes. I've also written a script to cover some of the automatable work that can given python-foo.spec will write a python3-foo.spec You can see the script here: http://dmalcolm.fedorapeople.org/python3-packaging/rpm2to3.py I got over-ambitious with this script: it can also be given a target srpm, and will then checkout the python 2 srpm, convert to python 3, then recursively walk the build requirements, building the python 3 packages in mock, attemping to build all a stack all the way up to the given srpm... well, that was the theory. However, most packages seem to need at least a little manual cleanup, and so I never managed to get far up the stack - and this is no substitute for actually engaging with the various upstream projects and working on python 3 support in the manner that each upstream wants (e.g. do they want a unified trunk for 2 and 3 vs separate branches) Thoughts? Dave [1] https://fedoraproject.org/wiki/Features/Python3F13 [2] See https://bugzilla.redhat.com/showdependencytree.cgi?id=530636 for the full details. From tim.lauridsen at googlemail.com Tue Nov 24 06:46:41 2009 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Tue, 24 Nov 2009 07:46:41 +0100 Subject: Python 3 packaging In-Reply-To: <1257898405.8419.312.camel@brick> References: <1257898405.8419.312.camel@brick> Message-ID: <4B0B8151.8010806@googlemail.com> On 11/11/2009 01:13 AM, David Malcolm wrote: > I'm working on a python 3 stack for Fedora 13, parallel-installable with > the default python 2 stack [1] > > I've attempted to package python 3, and package some python modules for > python 3. So far, I've got a "python3-rpm", a "python3-lxml", and two > different ways of packaging "python3-setuptools", though none of these > are actually in our CVS yet [2]. > > Thanks everyone for your help so far. > > In doing so, I've been writing some proposals on packaging guidelines > for Python 3 - both for secondary python runtimes, and for modules for > them. > > You can see what I've written so far here: > https://fedoraproject.org/wiki/PackagingDrafts/Python3 > > Obviously this is a work in progress but hopefully makes sense as far as > it goes. > > I've also written a script to cover some of the automatable work that > can given python-foo.spec will write a python3-foo.spec > > You can see the script here: > http://dmalcolm.fedorapeople.org/python3-packaging/rpm2to3.py > > I got over-ambitious with this script: it can also be given a target > srpm, and will then checkout the python 2 srpm, convert to python 3, > then recursively walk the build requirements, building the python 3 > packages in mock, attemping to build all a stack all the way up to the > given srpm... well, that was the theory. However, most packages seem to > need at least a little manual cleanup, and so I never managed to get far > up the stack - and this is no substitute for actually engaging with the > various upstream projects and working on python 3 support in the manner > that each upstream wants (e.g. do they want a unified trunk for 2 and 3 > vs separate branches) > > Thoughts? > Dave > > Look very nice, looking forward to test it, when the needed stuff hits the F13 repos. Thanks for the good work. Tim