After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 584633 - gst-python uses "#!/usr/bin/env python"
gst-python uses "#!/usr/bin/env python"
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-python
git master
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-06-02 17:00 UTC by Brian Cameron
Modified: 2012-12-17 11:36 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
patch we are currently using (7.14 KB, patch)
2009-06-02 17:19 UTC, Brian Cameron
rejected Details | Review

Description Brian Cameron 2009-06-02 17:00:20 UTC
Many files in gst-python uses "#!/usr/bin/env python".  However, this causes problems on Solaris because we build the gst-python module for both Python 2.4 and Python 2.6, and /usr/bin/python is a symlink to Python 2.4

We would prefer if our Python 2.6 packages did not depend on Python 2.4, so to fix this we have to hack the files installed with the Python 2.6 packages to specify "#!/usr/bin/python2.6" directly.

It would be nicer if gst-python could use some mechanism to specify the actual version of Python being used in the scripts instead of using "#!/usr/bin/env python".

There are 25 files in gst-python which have this issue.  Attached is the patch we are currently using with our gst-python 2.6 packages to hack the strings to point to the right version of Python.

I suppose this could be better addressed by changing all these files to ".in" files and generating them with the right string at configure time.  Though I am not sure if this is the best approach, so I wanted to get feedback from the maintainers.  Thanks.
Comment 1 Olivier Crête 2009-06-02 17:14:06 UTC
This seems more like Solaris has the wrong symlink. What will happen when we switch to python 2.7.. 
Comment 2 David Schleef 2009-06-02 17:17:03 UTC
I think you mean changing '/usr/bin/env python' to '/usr/bin/env python2.6'.
Comment 3 Brian Cameron 2009-06-02 17:19:43 UTC
Created attachment 135830 [details] [review]
patch we are currently using
Comment 4 Brian Cameron 2009-06-02 17:22:29 UTC
On Solaris, the symlink needs to remain at Python 2.4 for stability purposes.  At some point in the future, we will need to go through the Sun EOL/EOF process to change this.  However, that will probably not happen until we settle on which version of Python we want to support moving forward.  However, that is really a non-issue.  Even if the symlink changed to Python2.6, we would then have a similar problem with the gst-python 2.4 code.

What is the difference of using "#!/usr/bin/python2.6" and "#!/usr/bin/env python2.6"?  The code seems to work fine with "#!/usr/bin/python2.6".
Comment 5 David Schleef 2009-06-02 17:32:53 UTC
/usr/bin/env allows you to change the PATH to use a different python.
Comment 6 Tim-Philipp Müller 2010-03-22 12:53:34 UTC
What's up with this? Is this is a WONTFIX or do we want/need to change things to #!/usr/bin/env python2.6 instead?
Comment 7 Brian Cameron 2010-03-22 20:03:55 UTC
It would be better if you could just configure gst-python to use a specified version of PYTHON.  For example, if you set the PYTHON environment variable before configuring to a specific version, it should honor that, and default back to "#!/usr/bin/env python" if none is specified.  Other modules work this way.
For example, note gobject-introspection version 0.6.9:

The configure.ac file uses AM_PATH_PYTHON like this which sets PYTHON to the executable name.

AC_MSG_CHECKING([whether Python support is requested])
AM_PATH_PYTHON([2.5])

Then the python script tools/g-ir-scanner.in has this to specify the "#!" line at the beginning.

#!@PYTHON@

Wouldn't it make sense to use this sort of flexible mechanism that other GNOME modules are using already?
Comment 8 Tim-Philipp Müller 2010-03-24 00:04:03 UTC
Well, they only have one single file, not quite the same. pygtk might be a better comparison, and they seem to do exactly the same as pygst.
Comment 9 Brian Cameron 2010-03-24 07:09:56 UTC
Yes, but most (if not all) of such files in pygtk2 are not installed, so setting PATH before building or running examples is reasonable.  

However, when a module installs files to the system, then it is more important to ensure that they work when people run them, and are not dependent on whether they have PATH set properly.
Comment 10 Sebastian Dröge (slomo) 2011-05-20 06:38:04 UTC
How do we want to move forward here? The attached patch is definitely wrong, we should not hardcode to python 2.6 in all cases but let configure figure this out somehow.
Comment 11 Tobias Mueller 2011-09-12 09:03:38 UTC
Reopening as I don't see any open non-developer issue.

I feel, however, that this is a WONTFIX, because hard coding the Python version doesn't feel right.
Comment 12 Brian Cameron 2011-09-13 05:50:45 UTC
I was never suggesting that the version of Python should be hardcoded.  I was only suggesting that it be possible to configure gst-python to use a specific version of Python if desired.  It seems fine to me if the default value is
"#!/usr/bin/env python", but it would be nice if you could specify something more specific if you wanted.
Comment 13 David Schleef 2011-09-17 20:32:04 UTC
Two possible solutions:

- Change all the python scripts to blah.py.in, and have autoconf convert them at configure time.

- Hack the install target to fix them on install.

- Use '#!${prefix}/libexec/gstreamer-0.10/python-for-gstreamer' and put a script there to find the right python.  I'm not certain this would actually work, and notably would also require a) above.

- Complain to Guido van Rossum that this should really be fixed in python.

(Sorry, my internal counter is off.)
Comment 14 Sebastian Dröge (slomo) 2012-12-17 11:36:46 UTC
Closing this bug now, gst-python is only an extension module to pygi now and this bug doesn't make much sense anymore in this context.