[Starlingx-discuss] MultiOS: call of python via #!/usr/bin/env
Hello, We have a error raised by the Open Build System from OpenSUSE (OBS) due to the use of "#!/usr/bin/env" as interpreter. This stops the OBS to correctly detect dependencies. The use of /usr/bin/env is tricky as it creates an undefined build/run dependency on the target. Could someone explains why such trick is used ? I would need to get rid of it. Just want to find what will be required to be changed. If this is just to call python2 then #!/usr/bin/python2 would do. Thanks. -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre [ 10s] worker-utils.noarch: E: env-script-interpreter (Badness: 9) /usr/bin/topology.py /usr/bin/env python [ 10s] This script uses 'env' as an interpreter. For the rpm runtime dependency [ 10s] detection to work, the shebang #!/usr/bin/env python needs to be patched into [ 10s] #!/usr/bin/python otherwise the package dependency generator merely adds a [ 10s] dependency on /usr/bin/env rather than the actual interpreter /usr/bin/python. [ 10s] Alternatively, if the file should not be executed, then ensure that it is not [ 10s] marked as executable or don't install it in a path that is reserved for [ 10s] executables.
On 2019-09-11 11:06:52 +0200 (+0200), Dominig ar Foll (Intel Open Source) wrote:
We have a error raised by the Open Build System from OpenSUSE (OBS) due to the use of "#!/usr/bin/env" as interpreter. This stops the OBS to correctly detect dependencies. The use of /usr/bin/env is tricky as it creates an undefined build/run dependency on the target.
Could someone explains why such trick is used ?
The short answer is that, historically, it was hard to guess what the full path to a particular script interpreter might be on any given system, but env is pretty much always at a known location so can be used to perform a dynamic path search for the named interpreter executable. This was a popular technique to improve script portability, but has also fallen victim to "cargo cult" behavior in the years since... developers just repeat the pattern without considering whether there's still any reason to do so.
I would need to get rid of it. Just want to find what will be required to be changed.
If this is just to call python2 then #!/usr/bin/python2 would do. [...]
Assuming the interpreter you want will always be available at /usr/bin/python2 on systems where these scripts are meant to be run, that's the recommended solution, yes. You can also use some distbuild-time routine to patch the shebang lines of all scripts to refer to the correct interpreter path for the target system if it differs from the norm. -- Jeremy Stanley
On 11/09/2019 15:35, Jeremy Stanley wrote:
[...]
Assuming the interpreter you want will always be available at /usr/bin/python2 on systems where these scripts are meant to be run, that's the recommended solution, yes. You can also use some distbuild-time routine to patch the shebang lines of all scripts to refer to the correct interpreter path for the target system if it differs from the norm.
As the target OS are all of Linux type, a python link will always be available at /usr/bin/python. As for the time being we want to enforce python2, I will propose to replace all the call to /usr/bin/env by a direct call to python. Remains to decide if we call directly python2 or just python. For me enforcing python2 by the OBS build system is easy (a simple "prefer: python2" statement in "project config" , so I would be happy to not enforce the pythin release on a per packet basis, but the people working on Pythin3 support may have a different opinion that I would like to know. Thanks. -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre
On 2019-09-11 16:05:15 +0200 (+0200), Dominig ar Foll (Intel Open Source) wrote: [...]
Remains to decide if we call directly python2 or just python. For me enforcing python2 by the OBS build system is easy (a simple "prefer: python2" statement in "project config" , so I would be happy to not enforce the pythin release on a per packet basis, but the people working on Pythin3 support may have a different opinion that I would like to know.
The "python" (or "python2") and "python3" executables are interpreters for different programming languages. General consensus is that making a "python3" interpreter available as "python" is incorrect. A few distros have gone against this advice (notably Arch Linux), and have created a fair amount of pain for software authors as a result. I recommend using either #!/usr/bin/python2 or #!/usr/bin/python3 for clarity, and avoiding #!/usr/bin/python in new scripts if possible (but certainly never put #!/usr/bin/python in a Python-3.x-only script and expect the underlying system to provide a python3-compatible interpreter at /usr/bin/python, that's just asking for trouble). -- Jeremy Stanley
On Wed, Sep 11, 2019 at 9:25 AM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2019-09-11 16:05:15 +0200 (+0200), Dominig ar Foll (Intel Open Source) wrote: [...]
Remains to decide if we call directly python2 or just python. For me enforcing python2 by the OBS build system is easy (a simple "prefer: python2" statement in "project config" , so I would be happy to not enforce the pythin release on a per packet basis, but the people working on Pythin3 support may have a different opinion that I would like to know.
The "python" (or "python2") and "python3" executables are interpreters for different programming languages. General consensus is that making a "python3" interpreter available as "python" is incorrect. A few distros have gone against this advice (notably Arch Linux), and have created a fair amount of pain for software authors as a result. I recommend using either #!/usr/bin/python2 or #!/usr/bin/python3 for clarity, and avoiding #!/usr/bin/python in new scripts if possible (but certainly never put #!/usr/bin/python in a Python-3.x-only script and expect the underlying system to provide a python3-compatible interpreter at /usr/bin/python, that's just asking for trouble). -- Jeremy Stanley
So we agree that either #!/usr/bin/python2 or #!/usr/bin/python3 is better than #!/usr/bin/env . Am I right ? how many files needs this change ?
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On 11/09/2019 16:54, Victor Rodriguez wrote:
So we agree that either #!/usr/bin/python2 or #!/usr/bin/python3 is better than #!/usr/bin/env . Am I right ? how many files needs this change ?
Unfortunately that trick has been used a lot. It was obviously systematic. for all script calls 589 dominig@dominig-t480:~/starlingx/git> grep -R --exclude-dir=\.* -F '#!/usr/bin/env' * |wc -l 589 Only for python 301 dominig@dominig-t480:~/starlingx/git> grep -R --exclude-dir=\.* -F '#!/usr/bin/env python' * |wc -l 301 -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre
Hello, due the number of files with that error, I have enabled a work around. Each packages on th eOBS has not an rpmlintrc file which reduce the badness of that error. I did not put is to 0 so, it will still be listed in the build log file. ----- MypackageName.rpmlintrc ---------- setBadness('script-without-shebang', 2) --------------------------------------------------------- The issue with python2 and 3 selection will still need to be tackled and at that time, it would be nice to correct those shebang. Dominig On 11/09/2019 17:54, Dominig ar Foll (Intel Open Source) wrote:
On 11/09/2019 16:54, Victor Rodriguez wrote:
So we agree that either #!/usr/bin/python2 or #!/usr/bin/python3 is better than #!/usr/bin/env . Am I right ? how many files needs this change ? Unfortunately that trick has been used a lot. It was obviously systematic.
for all script calls 589 dominig@dominig-t480:~/starlingx/git> grep -R --exclude-dir=\.* -F '#!/usr/bin/env' * |wc -l 589
Only for python 301 dominig@dominig-t480:~/starlingx/git> grep -R --exclude-dir=\.* -F '#!/usr/bin/env python' * |wc -l 301
-- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre
participants (3)
-
Dominig ar Foll (Intel Open Source)
-
Jeremy Stanley
-
Victor Rodriguez