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

David Malcolm dmalcolm at
Thu Jan 14 21:56:23 UTC 2010

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 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 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/ 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:

Or we could use a "python3-" prefix, leading to:

Or something involving directories and the PATH environment variable,
leading perhaps to:

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

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



More information about the devel mailing list