Use (eg) #!/usr/bin/env python over #!/usr/bin/python
Patch attached that uses (eg)
#!/usr/bin/env python over
- Target version changed from Tails_3.12 to Tails_3.13
- Feature Branch set to feature/15844-use-env-in-python-shebang
The patch doesn't apply, so I did a search and replace on
!/usr/bin/python myself. I also changed the
fillram shebang to use
python3, which will solve #15845. Now waiting for Jenkins test results.
/me is eager to learn: why do we want to do this? FWIW my
/usr/binhas 286 instances of
/usr/bin/python*vs. 35 instances of
intrigeri: That's a best practice for managing Python versions. I don't think it really matters in the context of Tails, but for example if you would install Python to /usr/local/bin@, then the shebang
/usr/bin/python would use the wrong version, while
/usr/bin/env just always uses the one
env finds first in
$PATH. Also, many Python developers use one of the many tools for virtual Python environments, some of which modify the
$PATH variable in order to specify the correct Python version for the environment.
The change to the new shebang caused oniongrater to fail, so I reverted this change for oniongrater.
After that, the only remaining failing test is the fillram test. It fails because
pidof -x apparently doesn't find processes started with
/usr/bin/env python instead of
/usr/bin/python. We use
pidof -x on multiple occasions in our test suite, so if any of the other scripts for which we changed the shebang is called via any of the helper functions that use
pidof -x, we will run into this issue again in the future. So we would have to find a workaround for all occasions where we currently use
Since the improvement we gain from this ticket is minor and solely pro forma, I suggest we don't spend even more time on it and reject it instead. If we do that, I could create a separate branch for #15845 so we can still test and merge that one.
- Status changed from In Progress to Rejected
Since the improvement we gain from this ticket is minor and solely pro forma, I suggest we don't spend even more time on it and reject it instead.
If we do that, I could create a separate branch for #15845 so we can still test and merge that one.
Yes, please :)