On Fri, Oct 30, 2009 at 12:11:11PM -0400, David Malcolm wrote:
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)
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.
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
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'd apply your rules to allow either of the following: - python3-wxPython - python3-wx
Does the "purely a module" vs "is something uservisible" vs "is a stack" distinction sound sane?
It sounds sane but isn't really :-( let's take a few cases, yum, gourmet, setuptools, and bzr.
yum is used by most people as an application. It has both a private library in /usr/share/yum and a public library in %{python_sitelib}/yum. Numerically, most consumers of yum are plugins to yum (so they'd need to be written in the same python version as yum). However, there are users of the public library that are their ownstandalone tools. Those tools could be ported to python3 independently of yum itself.
gourmet is a gtk application. It is largely implemented as a library in %{python_sitelib}/gourmet.
setuptools is two python modules: setuptools and pkg_resources. It also has a script, easy_install. For many end users, easy_install is becoming the way that they use setuptools but for developers, pkg_resources is the primary use. (although developers are coming to use easy_install as well especially coupled with virtualenv).
bzr is a command line version control system and a python library. bzr takes plugins. The library is used in other aps that want to integrate with bzr. (bzr-eclipse, bzr-explorer, etc). Everything except a small script for running the commandline are in %{python_sitelib}/bzrlib.
Ways to deal with this: -Yum * yum could be split into a main yum package that includes /usr/bin/yum and the private library. Whether this is python2 or 3 doesn't matter yet. It would also have python-yum and python3-yum packages that has the public library available to both versions of yum. This makes sense to me because yum is well written and organized in this sense.
-gourmet * gourmet has plugins. It's also installed into the public library location. I don't know of anything that uses the libraries, though (not even external plugins). We could continue to treat this as a pure application at this time and just install a gourmet package where python2/3 is an implementation detail that does not need to be shown.
-setuptools * setuptools can be split to have a subpackage named simply "easy_install" with the easy_install script. This is a bit odd as the script is just a thin wrapper against code in the setuptools module (setuptools is not organized around public and private interfaces like yum is). In this scenario, you'd have python-setuptools, python3-setuptools, easy_install and easy_install-3 (if the maintainers of python-setuptools and python3-setuptools couldn't agree on having a single script). End users are used to getting easy_install from the setuptools package so I don't think this helps them much.
* The packages are called python-setuptools and python3-setuptools and we ignore the fact that there's a script in the package.
-bzr * UGH! I think we'll need to split these packages artificially and somewhat inefficiently: bzr package with the /usr/bin/bzr script. python3-bzrlib and python-bzrlib packages for the library. Note that if the upstream community ports to python3 all at the same time, we wouldn't have to worry about this. So probably we continue to have a monolithic bzr package until bzr/bzrlib is ported to python3. Then, if needed for other front end consumers of bzrlib, we make the split like this: python-bzrlib (python2), bzr (python3), python3-bzrlib (is this one necessary?)
-Toshio