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 575983 - pitivi doesn't find Python 2.6 well
pitivi doesn't find Python 2.6 well
Status: RESOLVED NOTABUG
Product: pitivi
Classification: Other
Component: General
Git
Other opensolaris
: Normal normal
: 0.13.4
Assigned To: Pitivi maintainers
Pitivi maintainers
Depends on:
Blocks:
 
 
Reported: 2009-03-19 16:27 UTC by Brian Cameron
Modified: 2009-09-12 09:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch fixing issue (832 bytes, patch)
2009-03-19 16:28 UTC, Brian Cameron
needs-work Details | Review

Description Brian Cameron 2009-03-19 16:27:38 UTC
On Solaris, /usr/bin/python points to Python 2.4 and we also ship Python 2.6 as /usr/bin/python2.6.  I set the PYTHON environment variable to "/usr/bin/python2.6" and run configure.  However, pitivi doesn't seem to find Python 2.6
and fails because it ends up using 2.4.

The attached patch fixes this problem.  I'm not sure this is the best way to fix this, but I wanted to point out this error and see if this could be fixed upstream.
Comment 1 Brian Cameron 2009-03-19 16:28:17 UTC
Created attachment 130980 [details] [review]
patch fixing issue
Comment 2 Edward Hervey 2009-03-19 17:05:13 UTC
I'm not entirely comfortable with these patches.

The one in bin/pitivi is a definite no-go. You're forcing python2.6.

As for the common/ modifications, we now use gstreamer's common module, so we should fix it there.
Comment 3 Brian Cameron 2009-03-19 19:00:36 UTC
I understand.   I'm not sure the "right" way to fix this.   I just wanted to share the issue that I ran into and see if the maintainers might have an idea how to make this work better.
Comment 4 Daniel Macks 2009-03-20 05:45:17 UTC
pitivi.in should probably specify @PYTHON@ so that the automake fragment that converts pitivi.in->pitivi substitutes the path to the python interp detected by autoconf (or as over-ridden by the PYTHON var when running ./configure)
Comment 5 Edward Hervey 2009-05-24 10:02:47 UTC
works perfectly fine on python 2.6 systems (running that on gentoo with 2.6, and the PPA (Jaunty using 2.6) also works fine).

Is this still an issue ?
Comment 6 Brian Cameron 2009-05-26 15:03:31 UTC
Yes, this is still an issue on Solaris.  I believe the problem is that on most other systems that support Python 2.6 /usr/bin/python points to python2.6.  On Solaris it points to python2.4.  So this causes problems for Python 2.6 programs which don't specify the version number.  The solution in comment #4 would probably work best.  Giving the user more flexibility in how python is configured to work with Pitivi is probably a good thing.

However, it isn't a huge problem for us to patch the code with the ugly patch in comment #1 as long as this is an issue.
Comment 7 Alessandro Decina 2009-09-02 13:44:30 UTC
We definitely shouldn't hardcode the path to python. We also shouldn't hardcode @PYTHON@. We don't build extensions so we can run perfectly fine with any python >= 2.5.
I'm convinced #!/usr/bin/env python is fine so i'm closing this.
Comment 8 Brian Cameron 2009-09-02 15:05:04 UTC
Unfortunately #!/usr/bin/env python does not work well on Solaris since the default /usr/bin/python is Python 2.4, which doesn't work with pitivi.

I know gnome-shell solved this problem by using 

AM_PATH_PYTHON([2.5])

Then the gnome-shell.in script uses this:

#!@PYTHON@

This way, whichever version of Python is found by configure is used, and you can define the PYTHON environment variable to be a specific version if, like on Solaris, you want to use a specific version.

Re-opening, since I don't see why the above solution shouldn't be used, when it is acceptable to be used in other modules, such as gnome-shell.
Comment 9 Alessandro Decina 2009-09-02 15:29:03 UTC
Depending on @PYTHON@ is wrong for us, since we are _not_ building any C modules, so we do _not_ depend on what version of python was used to run ./configure. We use AS_PATH_PYTHON just to make sure that a version of python >= 2.5 is available, since we depend on python 2.5 onwards.

Brian, I understand that solaris ships python2.4 by default, I don't see how that should be our problem though.
Comment 10 Daniel Macks 2009-09-02 16:22:43 UTC
What about using AM_PATH_PYTHON([2.5]), which obey the PYTHON env var if set, but then just before that set a default PYTHON="/usr/bin/env python" iff PYTHON var is not set? That way you default to Brian's prefered situation (letting AM_PATH_PYTHON check to make sure that this default is sufficient) but allow overriding if needed for any other arbitrary path if necessary.
Comment 11 Brian Cameron 2009-09-02 16:28:28 UTC
I wasn't trying to suggest that this was your problem.  I am just hoping that pitivi can be enhanced so that it is easier to customize what python to use.  I
was just highlighting that Solaris is a use-case for why this is useful.