[Python-Dev] Bilingual scripts (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat May 25 13:01:17 CEST 2013

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

More information about the Python-Dev mailing list