(Resurrecting the "Proposal: Python 3 in Fedora 13" thread; see: https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00054.html and https://fedoraproject.org/wiki/Features/Python3F13 )
On Thu, 2009-10-01 at 12:17 -0700, Toshio Kuratomi wrote:
On 10/01/2009 10:15 AM, David Malcolm wrote:
[snip]
"Naming convention" proposal: How does this sound:
- an rpm with a "python-" prefix means a python 2 rpm, of the
"default" python 2 minor version (for Fedora this will be the most recent stable upstream minor release, for EPEL it will be the minor release of 2 that came with the distro, so 2.4 for EPEL5)
- an rpm with a "python3-" prefix means a python 3 rpm, of the
"default" python 3 minor version (for Fedora this will be the most recent stable upstream release)
What about packages without a "python-" prefix? Proposal: If upstream has a naming convention for python2 vs python3, use it. Otherwise, add a "python3-" prefix to make things clear. I'm not sure about the details here. Examples?
+1 to the basics. There are a lot of details to work out:
Current naming conventions for Python packages are in https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28...
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.
(NB: I hope that we'll eventually be in a place where we can cut over embedders and users of python (e.g. gedit, gdb, mod_python etc) from 2 to 3; I'm _not_ suggesting we do anything to their names. Obviously such a move is a long way off)
This seems fine even though it's a bit redundant: python3-pygtk2 and python3-pygpgme.
We could combine: - the "always use a python3-" rule I invented just above (ahem) and - the "When in doubt, use the name of the module that you type to import it in a script" advice from the python module guidelines.
This would make the above examples be "python3-gtk" and "python3-gpgme"
What to do with things that have python in their suffix: gstreamer-python => gstreamer-python3? Or python3-gstreamer? Or python3-gstreamer-python? Most of these are subpackages of existing packages.
Again, following the combination of the two rules above: "python3-gstreamer"
A cornercase is the gnome-python2 package. These are python bindings to gnome2. gnome-python2 is the upstream name. For python3, do we want python3-gnome-python2, python3-gnome2, python3-gnome-python2 ? From my reading of "rpm -qi gnome-python2", the upstream name is
"gnome-python", so perhaps "python3-gnome" is the thing to use here?
Thoughts?
Dave
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?
Initially this sounds good to me. Because python 2 and python 3 are incompatible it's probably important we separate them at the packaging level, this seems like a good approach as any (even with some warts on the corner cases).
However package maintainers might not like the idea of having to maintain double the number of their packages for an interim period and I could see them wanting to have just one package that installs into both the python2 and python3 library locations. Also perhaps we don't want to inflate the number of python packages by 2x. Having not followed this discussion from it's outset I'm wondering if we might want to consider allowing a single python package to support both python versions. I'm sure there are multiple reasons why this is a horrible idea, but I thought I would throw it out for consideration and let it get shot down :-)
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?
Initially this sounds good to me. Because python 2 and python 3 are incompatible it's probably important we separate them at the packaging level, this seems like a good approach as any (even with some warts on the corner cases).
However package maintainers might not like the idea of having to maintain double the number of their packages for an interim period and I could see them wanting to have just one package that installs into both the python2 and python3 library locations. Also perhaps we don't want to inflate the number of python packages by 2x. Having not followed this discussion from it's outset I'm wondering if we might want to consider allowing a single python package to support both python versions. I'm sure there are multiple reasons why this is a horrible idea, but I thought I would throw it out for consideration and let it get shot down :-)
My original proposal [1] was that python 3 should be entirely separate from python 2
As a trial run, I took a packaged python module and got it to build with python 3. See: https://bugzilla.redhat.com/show_bug.cgi?id=531648
This is the separate-srpm approach, it would live as a separate package in CVS.
As an experiment, I tried hacking up the same module's specfile so that one build generates both 2 and 3 subpackages. You can see the result here: https://bugzilla.redhat.com/show_bug.cgi?id=531895
This approach requires the package to work with both python 2 and 3, which requires both an upstream maintainer and a downstream Fedora packager that care about both 2 and 3, working from a single source tree.
For supporting both 2 and 3 with a single built RPM (or something involving symlinked .py files?) I don't think that's possible: we don't want to add a python3 dependency to python 2 modules, and the precompiled bytecode optimization of imports requires version-specific .pyc/.pyo files - see bug 531117 (automating this in rpmbuild) and bug 531102 (adding a test to rpmlint to verify that it got it correct).
Dave
[1] See: https://www.redhat.com/archives/fedora-devel-list/2009-October/msg00054.html and https://fedoraproject.org/wiki/Features/Python3F13
On Oct 29, 2009, at 5:27 PM, David Malcolm wrote:
(NB: I hope that we'll eventually be in a place where we can cut over embedders and users of python (e.g. gedit, gdb, mod_python etc) from 2 to 3; I'm _not_ suggesting we do anything to their names. Obviously such a move is a long way off)
This seems fine even though it's a bit redundant: python3-pygtk2 and python3-pygpgme.
We could combine:
- the "always use a python3-" rule I invented just above (ahem) and
- the "When in doubt, use the name of the module that you type to
import it in a script" advice from the python module guidelines.
This would make the above examples be "python3-gtk" and "python3- gpgme"
My issue with a 'always use a python3-' rule is that the naming convention, to me, clarifies what the package is. For example:
python3-GeoIP => A python 3 library installed to site_packages mod_python3 => An Apache module built against/for python 3
Suggesting such a package should be 'python3-mod_python' might be confusing. Where as mod_python3 makes more sense. It also serves to keep the organization of packages similar. For example:
mod_python mod_python3 OR mod_python-python3 OR mod_python-py3
Will sit side by side in a yum list, or viewing a yum repo via browser... where as python3-mod_python would not list anywhere near mod_python.
What to do with things that have python in their suffix: gstreamer-python => gstreamer-python3? Or python3-gstreamer? Or python3-gstreamer-python? Most of these are subpackages of existing packages.
Again, following the combination of the two rules above: "python3-gstreamer"
Not sure I agree here, because '-python' is a sub package of gstreamer (and personally I hate subpackages that don't share the base package's base name). My vote would be for:
gstreamer-python (built against stock python) gstreamer-python3 OR gstreamer-python-py3 (built against python3)
A cornercase is the gnome-python2 package. These are python bindings to gnome2. gnome-python2 is the upstream name. For python3, do we want python3-gnome-python2, python3-gnome2, python3-gnome-python2 ? From my reading of "rpm -qi gnome-python2", the upstream name is
"gnome-python", so perhaps "python3-gnome" is the thing to use here?
In the case of gnome-python2 where the '2' references the version of gnome it is built for... well I'd say that is just a complete hozer and we should convince upstream to change the name. ;)
With regards to multiple versions of python in general, I'm maintaining such a setup currently via IUS [1] for RHEL/CentOS. It is essentially the same idea.. python26 with sub-packages such as python26-simplejson, python26-elixir, etc... as well as python31, python31-distribute. Additionally, there is mod_python26, mod_wsgi- python26, and mod_wsgi-python31. Not exactly applicable here in this thread, and there was no 'standards' discussion on naming conventions being that I'm currently the only developer... but regardless I wanted to point it out as perhaps a proof of concept of working with multiple versions of python (on RHEL/CentOS in my case).
For my purposes, and I don't know that this would follow Fedora ideals, my primary goal for python 3 was/is that the base package is available for use without effecting the system/stock python. I honestly don't think it is that important at this point to push all the python packagers to rebuild/maintain python3 counterparts of their packages in order for python3 to be added. With python3, and python3- distribute installed as a base, developers can begin testing/using/ building against python 3 and over time the supporting sub packages will be added as they become python 3 compatible. With python3- distribute, users can install the necessary [read missing] dependencies via easy_install-3 (same as they would with pear/pecl for PHP for their additional needs).
[1] See: http://iuscommunity.org, http://launchpad.net/ius
--- derks
packaging@lists.fedoraproject.org
-
BJ Dierkes -
David Malcolm -
John Dennis