5:27 p.m.
(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_...
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
5:42 p.m.
New subject: Proposal: naming convention for Python 3 packages and subpackages
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 :-)
--
John Dennis <jdennis(a)redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
7:15 p.m.
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
2:49 a.m.
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
5280
days inactive
5286
days old
packaging@lists.fedoraproject.org
3 comments
3 participants
participants (3)
-
BJ Dierkes -
David Malcolm -
John Dennis