[Python-Dev] Bilingual scripts

[Nick Coghlan]

On Sat, May 25, 2013 at 8:17 PM, Chris McDonough <chrism at plope.com> wrote:
> On Sat, 2013-05-25 at 17:57 +1000, Nick Coghlan wrote:
>> I think the simplest thing to do is just append the "3" to the binary
>> name (as we do ourselves for pydoc) and then abide by the
>> recommendations in PEP 394 to reference the correct system executable.
>
> I'm curious if folks have other concrete examples of global bindir
> executables other than nosetests and pydoc that need to be disambiguated
> by Python version.

Single source Python 2/3 packages don't have the problem. They can
either run with the system Python explicitly, or use "/usr/bin/env
python" in order to respect virtual environments.

The issue only exists for projects where Python 2 and Python 3 are
separate code bases with distinct scripts to be installed on the
target system. In my opinion, is just one more reason why single
source is a vastly superior alternative to treating the Python 2 and
Python 3 versions as separate applications.

> I'd hate to see it become standard practice to
> append "3" to scripts generated by packages which happen to use Python
> 3, as it will just sort of perpetuate its otherness.

Fedora only does it for stuff that has to straddle the two with a
parallel install as a system binary. If something is exclusive to Py3
(like "pyvenv") it doesn't get the suffix.

It's certainly not an elegant solution, but Python is far from the
only runtime platform afflicted by similar issues when it comes to
balancing the interests of distro developers wanting to build a single
integrated system against those of application developers wanting to
use more recent versions of their dependencies.

Longer term, we (Red Hat) want to better support application stacks
that are more independent of the system versions, while still being
fully under the control of the system package manager (to ease
security updates). The mechanism underlying that is Software
Collections, which is better described here:
http://developerblog.redhat.com/2013/01/28/software-collections-on-red-hat-enterprise-linux/

(The software collection system also exists in Fedora, as that's where
it was developed, but the main benefit there is to allow application
developers to use something *older* than what Fedora provides in the
system packages if there are backwards compatibility issues with an
update)

I have no idea if Debian are contemplating anything similar, but the
current situation where application developers have to choose between
letting distro vendors control the upgrade cycle of key dependencies
and divorcing themselves entirely from the benefits offered by the
system package manager is unsustainable in the long term.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia