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

[David Malcolm]

On Fri, 2010-01-15 at 10:55 -0500, Toshio Kuratomi wrote:
> On Fri, Jan 15, 2010 at 12:31:41PM +0100, Thomas Spura wrote:
> > Am Donnerstag, den 14.01.2010, 22:54 -0500 schrieb Toshio Kuratomi:
> > > On Thu, Jan 14, 2010 at 04:56:23PM -0500, David Malcolm wrote:
> > > > python3 is in rawhide and I'm hoping to build out the Python 3 stack
> > > > (help would be most welcome!)
> > > > 
> > > > I've run into a snag with the plan of building out parallel python 2 and
> > > > python 3 stacks [1]: What do we do about executables that live
> > > > in /usr/bin ?
> > > > 
> > > The first and most important question is why do we need a script for each
> > > stack?  I think the default should be to only have one version of scripts
> > > that either require python2 or python3.  Only in cases where the python2 and
> > > python3 versions do different things should we have both.
> > 
> > We need a script for each stack to test, if the programm also works with
> > python3. If some time in the future, everything works with python3, we
> > could swap the defaults and the scripts run with python3 on standard and
> > the python2 executables become /usr/bin/foo2 (or something like that).
> > And laterly maybe remove again the foo2 executable, if everything works.
> > 
> > If the scripts are not for each stack, we'll stick with to python2
> > forever.
> > 
> > Or how would you to the swap? (Sure it's to early to do it now, but some
> > time it needs to be done.)
> > 
> 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...)

= 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

= Script that "merely" uses Python =
These are "merely" scripts that use Python, rather than those for poking
at Python.  I think these should gradually be ported over to Python 3 as
the underlying dependencies are ported:
/usr/bin/alacarte
/usr/bin/audit2allow
/usr/bin/bittorrent-console
/usr/bin/bittorrent-curses
/usr/bin/bittorrent-tracker
/usr/bin/blueman-adapters
/usr/bin/blueman-applet
/usr/bin/blueman-assistant
/usr/bin/blueman-browse
/usr/bin/blueman-manager
/usr/bin/blueman-sendto
/usr/bin/blueman-services
/usr/bin/bodhi
/usr/bin/bugzilla
/usr/bin/bzr
/usr/bin/canto
/usr/bin/canto-fetch
/usr/bin/canto-inspect
/usr/bin/cftp
/usr/bin/changetracker-console
/usr/bin/chcat
/usr/bin/ckeygen
/usr/bin/conch
/usr/bin/debuginfo-install
/usr/bin/dtrace
/usr/bin/fedora-cert
/usr/bin/fedora-cvs
/usr/bin/fedora-hosted
/usr/bin/fedora-packager-setup
/usr/bin/find-repos-of-install
/usr/bin/git-cola
/usr/bin/gnome-about
/usr/bin/gnome-sudoku
/usr/bin/gtester-report
/usr/bin/gtk-builder-convert
/usr/bin/gtkdoc-depscan
/usr/bin/gupnp-binding-tool
/usr/bin/hg
/usr/bin/hg-ssh
/usr/bin/im
/usr/bin/invest-chart
/usr/bin/iotop
/usr/bin/istanbul
/usr/bin/koji
/usr/bin/ksflatten
/usr/bin/ksvalidator
/usr/bin/ksverdiff
/usr/bin/launchmany-console
/usr/bin/launchmany-curses
/usr/bin/libglade-convert
/usr/bin/lore
/usr/bin/mailmail
/usr/bin/maketorrent-console
/usr/bin/manhole
/usr/bin/mercurial-convert-repo
/usr/bin/mktap
/usr/bin/msgfmt.py
/usr/bin/msghack
/usr/bin/ndiff
/usr/bin/needs-restarting
/usr/bin/nosetests
/usr/bin/package-cleanup
/usr/bin/plague-client
/usr/bin/ps_mem.py
/usr/bin/purple-remote
/usr/bin/purple-url-handler
/usr/bin/pygettext.py
/usr/bin/pygmentize
/usr/bin/pyhtmlizer
/usr/bin/repoclosure
/usr/bin/repodiff
/usr/bin/repo-graph
/usr/bin/repomanage
/usr/bin/repoquery
/usr/bin/repo-rss
/usr/bin/reposync
/usr/bin/repotrack
/usr/bin/rpmdev-bumpspec
/usr/bin/rpmdev-checksig
/usr/bin/rpmdev-rmdevelrpms
/usr/bin/rpmdev-vercmp
/usr/bin/rpmdiff
/usr/bin/rst2html
/usr/bin/rst2latex
/usr/bin/rst2newlatex
/usr/bin/rst2pseudoxml
/usr/bin/rst2s5
/usr/bin/rst2xml
/usr/bin/rstpep2html
/usr/bin/rsvg
/usr/bin/sandbox
/usr/bin/sealert
/usr/bin/sepolgen-ifgen
/usr/bin/smtpd.py
/usr/bin/sphinx-autogen
/usr/bin/sphinx-build
/usr/bin/sphinx-quickstart
/usr/bin/squeal
/usr/bin/system-config-firewall
/usr/bin/system-config-firewall-tui
/usr/bin/tap2deb
/usr/bin/tap2rpm
/usr/bin/tapconvert
/usr/bin/tkconch
/usr/bin/torrentinfo-console
/usr/bin/trial
/usr/bin/twistd
/usr/bin/urlgrabber
/usr/bin/verifytree
/usr/bin/virt-clone
/usr/bin/virt-convert
/usr/bin/virt-image
/usr/bin/virt-install
/usr/bin/xml2po
/usr/bin/xmlproc_parse
/usr/bin/xmlproc_val
/usr/bin/yum
/usr/bin/yum-builddep
/usr/bin/yum-debug-dump
/usr/bin/yum-debug-restore
/usr/bin/yumdownloader
/usr/bin/yum-groups-manager


How does this sound?

Dave