[Starlingx-discuss] #! /usr/bin/env usage in python files
Folks, As you know we have been using OBS to start building openSUSE based rpms. One set of the warning / errors we have seen have to do with executable vs non-executable files based on location, premissions, and shebang contents. Sometimes it's an executable file (755) without a shebang, sometimes it's a file that contains shebang but is not executable (644) and there are other cases. We are working to submit permission fix-up and/or changes adding/removing shebang as needed Many of the scripts that do have shebang use /usr/bin/env which prevents the RPM runtime from correctly detecting the dependencies. So I would like to find out if there is any reason to not use /usr/bin/python directly or other executable as appropriate. I am aware that 'env' is used to help determine the explicit location of a binary in case it's in a different location on different OS implementations. For our proposes, currently all the OSes for the multiOS discussion have python in /usr/bin. If there is no issues, we can start submitting patches for review. Thanks Sau!
I think you can start submitting reviews to fix those. Over time, almost all the python scripts we had been using get created by PBR which sets up the shebang as either /usr/bin/python or /usr/bin/python2 Some components may not even have been converted to pbr yet. For cases where we created custom python scripts using /usr/bin/env, it's likely because google/stackoverflow indicate that's the preferred way. There's no specific reason to code it that way, as far as I can remember. We also have (or had) an inconsistency in how the license files in the spec files were published. Sometimes using doc, sometimes using the license keyword. Al -----Original Message----- From: Saul Wold [mailto:sgw@linux.intel.com] Sent: Monday, June 10, 2019 6:06 PM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] #! /usr/bin/env usage in python files Folks, As you know we have been using OBS to start building openSUSE based rpms. One set of the warning / errors we have seen have to do with executable vs non-executable files based on location, premissions, and shebang contents. Sometimes it's an executable file (755) without a shebang, sometimes it's a file that contains shebang but is not executable (644) and there are other cases. We are working to submit permission fix-up and/or changes adding/removing shebang as needed Many of the scripts that do have shebang use /usr/bin/env which prevents the RPM runtime from correctly detecting the dependencies. So I would like to find out if there is any reason to not use /usr/bin/python directly or other executable as appropriate. I am aware that 'env' is used to help determine the explicit location of a binary in case it's in a different location on different OS implementations. For our proposes, currently all the OSes for the multiOS discussion have python in /usr/bin. If there is no issues, we can start submitting patches for review. Thanks Sau! _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Wed, Jun 12, 2019 at 9:59 AM Bailey, Henry Albert (Al) <Al.Bailey@windriver.com> wrote:
For cases where we created custom python scripts using /usr/bin/env, it's likely because google/stackoverflow indicate that's the preferred way. There's no specific reason to code it that way, as far as I can remember.
Outside of a distro context the biggest reason I do that (use #!/usr/bin/env) is to make using virtual environments easier. I do not think that is a large concern here, the first place I could see it coming up is running in DevStack with virtual envs enabled, which is not as much of a thing as it should be and probably doesn't work now anyway. dt -- Dean Troyer dtroyer@gmail.com
On 2019-06-12 11:25:56 -0500 (-0500), Dean Troyer wrote: [...]
Outside of a distro context the biggest reason I do that (use #!/usr/bin/env) is to make using virtual environments easier. I do not think that is a large concern here, the first place I could see it coming up is running in DevStack with virtual envs enabled, which is not as much of a thing as it should be and probably doesn't work now anyway.
And for anything being installed as a proper Python package with entrypoint wrappers, those will get appropriate shebangs for the virtualenv/venv set in them anyway. -- Jeremy Stanley
participants (4)
-
Bailey, Henry Albert (Al)
-
Dean Troyer
-
Jeremy Stanley
-
Saul Wold