Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Canonicalize Python shebangs #9314

Merged
merged 1 commit into from
Sep 12, 2019
Merged

Conversation

ghost
Copy link

@ghost ghost commented Sep 11, 2019

Motivation and Context

/usr/bin/env python3 is the suggested shebang for Python in general (likewise for python2) and is conventional across platforms. This eases development on systems where python is not installed in /usr/bin (FreeBSD for example) and makes it possible to develop in virtual environments (venv) for isolating dependencies.

Many packaging guidelines discourage the use of /usr/bin/env, but since this is the canonical way of writing shebangs in the Python community, many packaging scripts are already equipped to handle substituting the appropriate absolute path to python automatically.

Some RPM package builders lacking brp-mangle-shebangs need a small fallback mechanism in the package spec to stamp the appropriate shebang on installed Python scripts.

Description

Shebangs in Python scripts are changed to use /usr/bin/env and the Makefile.am sed replacements for python3 to python2 are adjusted accordingly.

The RPM shebang mangling exception for test-runner.py is also removed, which probably should have been done in 3ba8cd6.

How Has This Been Tested?

We have been running this through the automated tests for a while in the FreeBSD PR.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Performance enhancement (non-breaking change which improves efficiency)
  • Code cleanup (non-breaking change which makes code smaller or more readable)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation (a change to man pages or other documentation)

Checklist:

@ghost ghost requested a review from rlaager September 11, 2019 14:56
Copy link
Member

@rlaager rlaager left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is reasonable.

@gdevenyi
Copy link
Contributor

@ghost
Copy link
Author

ghost commented Sep 11, 2019

I don't think this follows https://www.python.org/dev/peps/pep-0394/#for-python-script-publishers

Why not? I believe this is the part that applies:

In cases where the script is expected to be executed outside virtual environments, [...]
developers may either use a Python package installation tool that rewrites shebang lines for the installed environment, provide instructions on updating shebang lines interactively, or else use more specific shebang lines that are tailored to the target environment.

The packaging tools we use rewrite the shebang to target the specific environment the package is being built for. This is separate from changing python3 to python2. The shebangs are further mangled for packaging to something like /usr/bin/python3 or /usr/bin/python2 or whatever is appropriate for the system being targeted.

@ghost ghost force-pushed the python-shebangs branch from 4ee5a00 to 29b5826 Compare September 11, 2019 17:23
@ghost
Copy link
Author

ghost commented Sep 11, 2019

Updated to remove brp mangle exception for test-runner.py, which probably should have been done in 3ba8cd6

@ghost
Copy link
Author

ghost commented Sep 11, 2019

The three early test failures appear to be systems lacking /usr/lib/rpm/redhat/brp-mangle-shebangs. That should be detectable in the RPM spec so a fallback can be used instead. I will fix this in the next push.

@gdevenyi
Copy link
Contributor

I missed the rewrite code, sorry.

Copy link
Member

@gmelikov gmelikov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@gmelikov gmelikov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, there are problems in our test builders, e.g. centos 7.

@behlendorf behlendorf added the Status: Code Review Needed Ready for review and testing label Sep 11, 2019
@codecov
Copy link

codecov bot commented Sep 11, 2019

Codecov Report

Merging #9314 into master will decrease coverage by 0.03%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #9314      +/-   ##
==========================================
- Coverage   79.14%   79.11%   -0.04%     
==========================================
  Files         401      401              
  Lines      122077   122074       -3     
==========================================
- Hits        96617    96573      -44     
- Misses      25460    25501      +41
Flag Coverage Δ
#kernel 79.78% <ø> (+0.01%) ⬆️
#user 66.92% <ø> (+0.13%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d666206...6ba8734. Read the comment docs.

/usr/bin/env python3 is the suggested[1] shebang for Python in general
(likewise for python2) and is conventional across platforms. This eases
development on systems where python is not installed in /usr/bin
(FreeBSD for example) and makes it possible to develop in virtual
environments (venv) for isolating dependencies.

Many packaging guidelines discourage the use of /usr/bin/env, but since
this is the canonical way of writing shebangs in the Python community,
many packaging scripts are already equipped to handle substituting the
appropriate absolute path to python automatically.

Some RPM package builders lacking brp-mangle-shebangs need a small
fallback mechanism in the package spec to stamp the appropriate shebang
on installed Python scripts.

[1]: https://docs.python.org/3/using/unix.html?#miscellaneous

Signed-off-by: Ryan Moeller <[email protected]>
@ghost ghost force-pushed the python-shebangs branch from 29b5826 to 6ba8734 Compare September 12, 2019 13:07
@ghost
Copy link
Author

ghost commented Sep 12, 2019

Updated to provide a fallback method for mangling the Python shebangs on RPM builders lacking brp-mangle-shebangs. This should fix the three failed test runners.

@behlendorf behlendorf added Status: Accepted Ready to integrate (reviewed, tested) and removed Status: Code Review Needed Ready for review and testing labels Sep 12, 2019
@behlendorf behlendorf merged commit 4f342e4 into openzfs:master Sep 12, 2019
@ghost ghost deleted the python-shebangs branch September 13, 2019 03:56
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request Dec 24, 2019
/usr/bin/env python3 is the suggested[1] shebang for Python in general
(likewise for python2) and is conventional across platforms. This eases
development on systems where python is not installed in /usr/bin
(FreeBSD for example) and makes it possible to develop in virtual
environments (venv) for isolating dependencies.

Many packaging guidelines discourage the use of /usr/bin/env, but since
this is the canonical way of writing shebangs in the Python community,
many packaging scripts are already equipped to handle substituting the
appropriate absolute path to python automatically.

Some RPM package builders lacking brp-mangle-shebangs need a small
fallback mechanism in the package spec to stamp the appropriate shebang
on installed Python scripts.

[1]: https://docs.python.org/3/using/unix.html?#miscellaneous

Reviewed-by: Richard Laager <[email protected]>
Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: George Melikov <[email protected]>
Signed-off-by: Ryan Moeller <[email protected]>
Closes openzfs#9314
tonyhutter pushed a commit to tonyhutter/zfs that referenced this pull request Dec 27, 2019
/usr/bin/env python3 is the suggested[1] shebang for Python in general
(likewise for python2) and is conventional across platforms. This eases
development on systems where python is not installed in /usr/bin
(FreeBSD for example) and makes it possible to develop in virtual
environments (venv) for isolating dependencies.

Many packaging guidelines discourage the use of /usr/bin/env, but since
this is the canonical way of writing shebangs in the Python community,
many packaging scripts are already equipped to handle substituting the
appropriate absolute path to python automatically.

Some RPM package builders lacking brp-mangle-shebangs need a small
fallback mechanism in the package spec to stamp the appropriate shebang
on installed Python scripts.

[1]: https://docs.python.org/3/using/unix.html?#miscellaneous

Reviewed-by: Richard Laager <[email protected]>
Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: George Melikov <[email protected]>
Signed-off-by: Ryan Moeller <[email protected]>
Closes openzfs#9314
tonyhutter pushed a commit that referenced this pull request Jan 23, 2020
/usr/bin/env python3 is the suggested[1] shebang for Python in general
(likewise for python2) and is conventional across platforms. This eases
development on systems where python is not installed in /usr/bin
(FreeBSD for example) and makes it possible to develop in virtual
environments (venv) for isolating dependencies.

Many packaging guidelines discourage the use of /usr/bin/env, but since
this is the canonical way of writing shebangs in the Python community,
many packaging scripts are already equipped to handle substituting the
appropriate absolute path to python automatically.

Some RPM package builders lacking brp-mangle-shebangs need a small
fallback mechanism in the package spec to stamp the appropriate shebang
on installed Python scripts.

[1]: https://docs.python.org/3/using/unix.html?#miscellaneous

Reviewed-by: Richard Laager <[email protected]>
Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: George Melikov <[email protected]>
Signed-off-by: Ryan Moeller <[email protected]>
Closes #9314
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Accepted Ready to integrate (reviewed, tested)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants