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 325951 - Path to python not respected
Path to python not respected
Status: RESOLVED FIXED
Product: gnome-schedule
Classification: Other
Component: general
1.0.0
Other Mac OS
: Normal normal
: ---
Assigned To: GNOME Schedule Maintainers
GNOME Schedule Maintainers
Depends on:
Blocks: 325978
 
 
Reported: 2006-01-06 08:01 UTC by Daniel Macks
Modified: 2006-01-06 16:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Daniel Macks 2006-01-06 08:01:43 UTC
The python interpretter that I want gnome-schedule to use is not in /usr/bin (and isn't even called 'python'), so I do:

  PYTHON=/sw/bin/python2.4 ./configure --prefix=/sw

and see:

checking for python version... 2.4
checking for python platform... darwin
checking for python script directory... ${prefix}/lib/python2.4/site-packages
checking for python extension module directory... ${exec_prefix}/lib/python2.4/site-packages
[...]
checking PYTHONPATH env variable for PyGTK... /sw/lib/python2.4/site-packages
checking for gtk.glade... found

I know PYTHON is being handled correctly so far. If /usr/bin/python were leaking in, it would be 2.3, the module directory would be different, and gtk.glade would not be found.

Then I do:

  make && make install

but the /sw/bin/gnome-schedule I get still uses /usr/bin/python. That's bad: some of the modules in the PYTHONPATH dir are not usable with that python interp because it is a different version, is compiled with different options and, is not binary-compatible with the one I specified in PYTHON. Consider the extreme situation where /usr/bin/python may not even exist.

gnome-schedule.py and scheduleapplet.py have the same problem, both beginning #!/usr/bin/python, but I don't know if those files are ever executed directly so it may not matter. OTOH, if they aren't why do they have #! lines?
Comment 1 Daniel Macks 2006-01-06 08:13:24 UTC
The same problem affects bonobo/servers/GNOME_GnomeSchedule.server. Hmm...later in the ./configure output, I see:

checking for python... /usr/bin/python

which appears to be controllable by PYTHON_CONFIG instead of PYTHON. If I pass both of those pointing to /sw/bin/python2.4, I get correct paths in the bonobo server and the main gnome-schedule script. The two *.py #! lines are not changed. Why are there two variables needed here, the less-standard of which is the critical control, and neither of which appears to be documented?
Comment 2 Gaute Hope 2006-01-06 12:08:47 UTC
The shebangs has been removed. Ok, what is the correct variable to use? @PYTHON_CONFIG@ or just @PYTHON@ ? 
Comment 3 Gaute Hope 2006-01-06 12:43:32 UTC
I think the PYTHON variable is used by some predefined macros:
dnl check for python
dnl AM_PATH_PYTHON
AM_PATH_PYTHON

And PYTHON_CONFIG is a new variable introduced by gnome-shedule. 
Comment 4 Gaute Hope 2006-01-06 12:52:05 UTC
	* configure.ac: removed useless second check for python, removed PYTHON_CONFIG variable
	* updated files using PYTHON_CONFIG to be using PYTHON

Fixed. I hope. Now I should stop talking to myself.
Comment 5 Daniel Macks 2006-01-06 16:48:10 UTC
Ayup, PYTHON is indeed (more) standard as you noticed. Looks good!