View previous topic :: View next topic |
Author |
Message |
Dominique_71 Veteran
Joined: 17 Aug 2005 Posts: 1877 Location: Switzerland (Romandie)
|
Posted: Sat Jun 22, 2013 2:17 pm Post subject: Python 2 shebang |
|
|
Hi,
I have a python 2.7 software, and its shebang is "#!/usr/bin/env python2.7".
But I am not sure if it is the best shebang.
First, I want to distribute this software, and some links tell me it is best in that case to use "#!/usr/bin/python2.7", when others tell me it is best to use "#!/usr/bin/env python2.7" in any case. What are the pro and con of both solutions?
Second, it need python 2.7. With "#!/usr/bin/env python2.7", I am sure it will use python 2.7, but "python_replicate_script" (python-r1 eclass) bail with
Code: | * A file does not seem to have a supported shebang:
* file: /var/tmp/portage/x11-themes/fvwm-crystal-9999/image//usr/bin/fvwm-crystal.apps-python2.7
* shebang: #!/usr/bin/env python2.7 |
python_replicate_script work fine if I put "#!/usr/bin/env python2".
What is best, to keep #!/usr/bin/env python2.7 into the shebang and dont use python_replicate_script, or use #!/usr/bin/env python2 and python_replicate_script? _________________ "Confirm You are a robot." - the singularity |
|
Back to top |
|
|
smartass Apprentice
Joined: 04 Jul 2011 Posts: 189 Location: right behind you ... (you did turn around, didn't you?)
|
Posted: Sat Jun 22, 2013 2:49 pm Post subject: |
|
|
Are you sure it won't work with python2.{5,6} ? If it would, you can save yourself the hassle and use just python2. But I'm surprised such a thing is not supported, wonder why.
The pro of using env is that it will respect your PATH setting, which is often useful in complicated virtualenv environments and makes it more portable to other platforms. The overhead is negligible. The downside is that the effective process name is "python2", not the script name. This makes it harder to use `killall`.
Personally, I prefer the env solution, because when I want to package and distribute something, portability is a top priority and not being able to use killall is not a big problem, because IMHO a proper setup should track and clean up a child process and not rely on killall hacks. |
|
Back to top |
|
|
Dominique_71 Veteran
Joined: 17 Aug 2005 Posts: 1877 Location: Switzerland (Romandie)
|
Posted: Sat Jun 22, 2013 3:33 pm Post subject: |
|
|
OK, this a few scripts, some of them are managed by fvwm, the others are one go scripts when they are called, so killall is not an issue here.
Also, they are quite old, and the only change I made from the time I "inherited" this software, is a variable name change to make it compatible with python2.7. So, I suppose they will work with older versions, but I must test it to be 100% sure.
Thanks for the answer. _________________ "Confirm You are a robot." - the singularity |
|
Back to top |
|
|
TomWij Retired Dev
Joined: 04 Jul 2012 Posts: 1553
|
Posted: Sat Jun 22, 2013 5:53 pm Post subject: |
|
|
Doesn't this depend on how you set the eclass variables? More specifically, the supported targets. Could you show us the ebuild? |
|
Back to top |
|
|
Dominique_71 Veteran
Joined: 17 Aug 2005 Posts: 1877 Location: Switzerland (Romandie)
|
Posted: Sun Jun 23, 2013 10:18 am Post subject: |
|
|
TomWij wrote: | Doesn't this depend on how you set the eclass variables? More specifically, the supported targets. Could you show us the ebuild? |
Sure, It is here: bug 468860
Also, I reverted the shebang in the source to "#!/usr/bin/env python2", that imply this is not a problem anymore with python_replicate_script.
And it is in portage now. _________________ "Confirm You are a robot." - the singularity |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|