[Fedora-packaging] Proposal: naming convention for Python 3 packages and subpackages

[BJ Dierkes]

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