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