Owner

Current status

Detailed Description

Fedora ships numerous executables written in Python. Many of them contain the shebang line:
#!/usr/bin/env python

However, this makes it difficult to install alternative versions of Python on the system. If a user wishes e.g. to install python 3 on the system, and have a /usr/local/python in her PATH, this will break these executables.

These system executables are expecting to use the system python, and thus should use:
#!/usr/bin/python".

The shebang line should also contain carefully-chosen command line options for invoking python for a system executable.

FIXME: does this work? do the command-line args from the shebang get appropriately combined with those from the invocation of the exectuable?

As of Python 2.6 and 3.0, Python supports loading user-specific Python libraries, as per PEP-370, which is helpful for Python developers, but isn't appropriate for system executables, and could be a security issue. It can also lead to warnings from SELinux - see e.g. RHBZ #614025. The shebang line for a system executable should thus contain the "-s" argument, to suppress PEP-370.

Alternatively, we could add a /usr/bin/system-python-2 executable (or somesuch), which invokes python 2 in an appropriate way for a system executable, isolating the exact command-line arguments to be used in one place.

TODO: are any other command-line arguments appropriate?

Benefit to Fedora

Users will be able to parallel-install local copies of older and newer releases of Python on the system and add them to the front of their PATH without breaking these executables. (e.g. Python 2.4 for Zope, or Python 3)

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, and JBoss are trademarks or registered trademarks of
Red Hat, Inc. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community
maintained site. Red Hat is not responsible for content.