GNOME Bugzilla – Bug 575983
pitivi doesn't find Python 2.6 well
Last modified: 2009-09-12 09:45:16 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.
Created attachment 130980 [details] [review] patch fixing issue
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.
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.
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)
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 ?
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.
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.
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.
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.
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.
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.