Globally-visible executables with parallel python 2 and python 3 stacks

[David Malcolm]

On Fri, 2010-01-15 at 16:53 -0500, Toshio Kuratomi wrote:
> On Fri, Jan 15, 2010 at 11:45:05AM -0500, David Malcolm wrote:
> > On Fri, 2010-01-15 at 10:55 -0500, Toshio Kuratomi wrote:
> > > This reasoning (needed for testing) doesn't appeal to me at all.  The
> > > general case should be that we switch applications in rawhide from python2
> > > to python3.  Test those packages in rawhide.  If it works, then the nex
> > > version of Fedora ships with those scripts using the python3 interpreter.
> > 
> > I ran this on my F-12 laptop (running a mix of software, with a local
> > build of python3 and python3-setuptools):
> > [david at brick ~]$ (for f in /usr/bin/* ; do (file --brief $f | grep
> > python > /dev/null) && echo $f ; done) > python-executables.txt
> > [david at brick ~]$ wc -l python-executables.txt 
> > 142 python-executables.txt
> > 
> > I think that we can usefully split these python scripts into two
> > categories, as follows.   For those in the first category it makes sense
> > to keep both python 2 and python 3 versions around.  For those in the
> > second, we'd want to gradually move them over to Python 3 as the
> > dependencies are ported (which in itself is a large task...)
> > 
> I think this is the right general approach.  I wouldn't express the
> categoriesin quite the same manner, though:
> 
> > = Support files for the Python language =
> > These scripts are for working with the language itself, or a stack/major
> > library built on top of Python; a Python developer would typically want
> > both versions available for use, or for testing:
> > /usr/bin/2to3
> > /usr/bin/2to3-3
> > /usr/bin/bpython
> > /usr/bin/coverage
> > /usr/bin/django-admin
> > /usr/bin/easy_install
> > /usr/bin/easy_install-2.6
> > /usr/bin/easy_install-3.1
> > /usr/bin/g-ir-scanner
> > /usr/bin/idle
> > /usr/bin/idle3
> > /usr/bin/pydoc
> > /usr/bin/pydoc3
> > /usr/bin/pygtk-demo
> > /usr/bin/python2
> > /usr/bin/python2.6-config
> > /usr/bin/python3.1-config
> > /usr/bin/python3-config
> > /usr/bin/python-config
> > /usr/bin/testosterone
> > 
> When I look at these, I think the basic test I'd make is: do the binaries
> provide different functionality depending on whether you run the python2 or
> python3 version?  Something like 2to3 is an example of something that does
> not need to have both a python2 and python3 version.  It takes py2 input
> files and outputs py3 files.  There should not be any difference whether
> it's invoked with the python2 interpreter or the python3 interpreter. (OTOH,
> I can see making an exception to the general rule for things that are
> shipped in the python3 upstream package, which would allow 2to3 in).
I like this; I've written up some notes on this here:
https://fedoraproject.org/wiki/PackagingDrafts/Python3#Executables_in_.2Fusr.2Fbin

> Some of these I know are correct to be in this list (bpython, easy_install
> [although that's a limitation of easy_install; could be fixed in the
> future]), pygtk-demo, python*-config.
> 
> Others I'm not sure: coverage, django-admin, g-ir-scanner, idle,
> testosterone.  The question is basically: Does the program only operate on
> python2 xor python3 depending on which interpreter it was built with?
> 
> Are coverage and testosterone only able to evaluate python modules that are
> of matching type?  (Could be yes if they're attempting to run those modules
> in process).
Yes for both of these.

[snip questions about other executables]