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

[David Malcolm]

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 ?

For example if we have a 'console_scripts' in a setup.py shared between
python 2 and python 3 builds: these will spit out files in /usr/bin/,
and these will collide.

The immediate example I'm thinking of is python-coverage.  This
package's setup.py has:
    entry_points = {
        'console_scripts': [
            'coverage = coverage:main',
            ]
        },
which thus generates a /usr/bin/coverage executable (this is a python
script that runs another python script whilst generating code-coverage
information on the latter).  Where does the python3 version of this
executable go?

Similarly for the 'scripts' clause; see e.g. python-pygments:
Pygments-1.1.1/setup.py has:
    scripts = ['pygmentize'],
which thus leads to a /usr/bin/pygmentize executable (it's a utility to
do syntax-highlighting, so not a language-support feature as such;
still, having both py2 and py3 versions available seems worthwhile for
transition purposes).

One approach is to simply add a "3" or "-3" suffix to these paths. 
I've
already done this for python3-tools; "2to3" became "2to3-3"

In the above examples, this would lead to:
  /usr/bin/coverage-3
  /usr/bin/pymentize-3

Or we could use a "python3-" prefix, leading to:
  /usr/bin/python3-coverage
  /usr/bin/python3-pymentize

Or something involving directories and the PATH environment variable,
leading perhaps to:
  /usr/libexec/python-3.1/coverage
  /usr/libexec/python-3.1/pygmentize

Anyone got any better ideas?  Thoughts about which of the above is
preferrable?

Potentially we could automate the solution in python3-setuptools, so
that you don't need to fixup the build by hand in each setup.py.

Thoughts?
Dave

[1] https://fedoraproject.org/wiki/Features/Python3F13

[Jonathan Underwood]

2010/1/14 David Malcolm <dmalcolm(a)redhat.com&gt;:
>  Anyone got any better ideas?  Thoughts about which of the above is
>  preferrable? 
I am not sure it qualifies as "better" than your suggestions... but
the problem of different executables with the same name providing
equivalent functionality via a different implementation is pretty much
what the alternatives system is designed to deal with...

[David Malcolm]

On Thu, 2010-01-14 at 22:29 +0000, Jonathan Underwood wrote:
>  2010/1/14 David Malcolm <dmalcolm(a)redhat.com&gt;:
>  > Anyone got any better ideas?  Thoughts about which of the above is
>  > preferrable?
>  
>  I am not sure it qualifies as "better" than your suggestions... but
>  the problem of different executables with the same name providing
>  equivalent functionality via a different implementation is pretty much
>  what the alternatives system is designed to deal with... 
Thanks.  As I understand it, the alternatives system is a host-wide
configuration setting: only one set of things can be at use at a time on
a host; that seems too blunt for this, alas - I think people should be
able to use a mixture of programs written with both stacks.

Dave

[Jesse Keating]

On Thu, 2010-01-14 at 18:49 -0500, David Malcolm wrote:
>  
>  Thanks.  As I understand it, the alternatives system is a host-wide
>  configuration setting: only one set of things can be at use at a time on
>  a host; that seems too blunt for this, alas - I think people should be
>  able to use a mixture of programs written with both stacks.  
Alternatives is system wide, but it can be per application.  So you can
decide which apps use python3 and which use 2.6.

if you want to go further you can make it per-user with environment
modules.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Ville Skyttä]

On Friday 15 January 2010, Jesse Keating wrote:

>  Alternatives is system wide, but it can be per application. 
Per application alternatives, as in alternatives(8)?  How?

[Till Maas]

On Sat, Jan 16, 2010 at 11:14:53AM +0200, Ville Skyttä wrote:
>  On Friday 15 January 2010, Jesse Keating wrote:
>  
>  > Alternatives is system wide, but it can be per application.
>  
>  Per application alternatives, as in alternatives(8)?  How? 
If two versions of each application with different shebangs are
installed:
/usr/bin/foo.python3
/usr/bin/foo.python2
/usr/bin/foo -> /usr/bin/foo.python3
/usr/bin/bar.python2
/usr/bin/bar.python3
/usr/bin/bar -> /usr/bin/bar.python2

I guess, this is also possible:
Each application has a unique shebang, e.g. for /usr/bin/bar:
#! /usr/bin/python.bar
then /usr/bin/python.bar can be made to either point to /usr/bin/python
or /usr/bin/python3 using alternatives.

Regards
Till

[Ville Skyttä]

On Saturday 16 January 2010, Till Maas wrote:
>  On Sat, Jan 16, 2010 at 11:14:53AM +0200, Ville Skyttä wrote:
>  > On Friday 15 January 2010, Jesse Keating wrote:
>  > > Alternatives is system wide, but it can be per application.
>  >
>  > Per application alternatives, as in alternatives(8)?  How?
>  
>  If two versions of each application with different shebangs are
>  installed: 
[...]

Ah, I see, the apps themselves would be managed using alternatives, not python 
2 and 3.

But what's the benefit of alternatives for this?  Is the intent to provide 
sysadmins a way to change which python version of an app would be the system 
default?

If not, why not just pick what we want to be the default for each app, and use 
a plain old symlink in packages to point to it?  Changing what we want to be 
the default would require package updates anyway, and it seems to me that 
alternatives just complicates things and provides people a way to shoot 
themselves in the foot, e.g prevent that default change from happening when 
that package update lands (in addition to changing it at will without any 
package updates in question) which might not be a good thing.

[Toshio Kuratomi]

On Sat, Jan 16, 2010 at 12:45:24PM +0200, Ville Skyttä wrote:
>  
>  But what's the benefit of alternatives for this?  Is the intent to provide 
>  sysadmins a way to change which python version of an app would be the system 
>  default?
>  
>  If not, why not just pick what we want to be the default for each app, and use 
>  a plain old symlink in packages to point to it?  Changing what we want to be 
>  the default would require package updates anyway, and it seems to me that 
>  alternatives just complicates things and provides people a way to shoot 
>  themselves in the foot, e.g prevent that default change from happening when 
>  that package update lands (in addition to changing it at will without any 
>  package updates in question) which might not be a good thing. 
Additionally, I think alternatives would only work for exactly the scripts
that I think don't need to have a python2 and python3 version.  ie: The
scripts that do exactly the same thing whether they're run via pythn2 or
python3.  AFAICS, we should just have those scripts/packages choose to
install the python2 version xor the python3 version.  The end user gets no
visible changes (except maybe different bugswhich we are supposed to just
fix).  In cases where the two scripts do different things, alternatives
shouldn't be used anyway.

-Toshio

[Jesse Keating]

On Sat, 2010-01-16 at 13:09 -0500, Toshio Kuratomi wrote:
>  On Sat, Jan 16, 2010 at 12:45:24PM +0200, Ville Skyttä wrote:
>  > 
>  > But what's the benefit of alternatives for this?  Is the intent to provide 
>  > sysadmins a way to change which python version of an app would be the system 
>  > default?
>  > 
>  > If not, why not just pick what we want to be the default for each app, and use 
>  > a plain old symlink in packages to point to it?  Changing what we want to be 
>  > the default would require package updates anyway, and it seems to me that 
>  > alternatives just complicates things and provides people a way to shoot 
>  > themselves in the foot, e.g prevent that default change from happening when 
>  > that package update lands (in addition to changing it at will without any 
>  > package updates in question) which might not be a good thing.
>  
>  Additionally, I think alternatives would only work for exactly the scripts
>  that I think don't need to have a python2 and python3 version.  ie: The
>  scripts that do exactly the same thing whether they're run via pythn2 or
>  python3.  AFAICS, we should just have those scripts/packages choose to
>  install the python2 version xor the python3 version.  The end user gets no
>  visible changes (except maybe different bugswhich we are supposed to just
>  fix).  In cases where the two scripts do different things, alternatives
>  shouldn't be used anyway.
>   
I wasn't really suggesting we use alternatives, I was merely pointing
out the way in which alternatives could work and also pointing out the
alternative of environment modules.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[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.

-Toshio

[Thomas Spura]

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.)

	Thomas

[Toshio Kuratomi]

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.

-Toshio

[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@brick ~]$ (for f in /usr/bin/* ; do (file --brief $f | grep
python > /dev/null) && echo $f ; done) > python-executables.txt
[david@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

[Toshio Kuratomi]

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@brick ~]$ (for f in /usr/bin/* ; do (file --brief $f | grep
>  python > /dev/null) && echo $f ; done) > python-executables.txt
>  [david@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).

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).

Does django-admin generate python2 or python3 templates depending on which it
was built for and does not have a commandline switch to generate
templates for the other (or other functionality... maybe there's
a django-admin shell command where the python interpreter and the build of
django-admin must match).

Does g-ir-scanner only create python2 or python3 output?  It can't do one or
the other based on a command line switch?

Does idle3 not do something that idle2 can do (like dosource highlighting of
python2 files)? (Thisisbundled with the python3 package, though)

-Toshio

[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@brick ~]$ (for f in /usr/bin/* ; do (file --brief $f | grep
>  > python > /dev/null) && echo $f ; done) > python-executables.txt
>  > [david@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_.2F...

>  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]

[Colin Walters]

On Fri, Jan 15, 2010 at 4:45 PM, David Malcolm <dmalcolm(a)redhat.com&gt; wrote:
>  = Support files for the Python language = 
>  /usr/bin/g-ir-scanner 
I don't see any intrinsic value in having both versions of
g-ir-scanner available; this one should be in the other category, it's
just a program which happens to be implemented in Python.

(Now, if in the future we have an extension system for it as has been
considered, things get dramatically more complicated, but that's not
likely soon)