| msg88066 - (view) |
Author: (soundmurderer) |
Date: 2009-05-19 05:52 |
| The PYTHONHOME variable does not allow complete control over making a Python installation find its own libs because "lib/pythonX.Y" gets appended to it, see: http://docs.python.org/using/cmdline.html#envvar-PYTHONHOME For example, let's say my Python installation is here: /home/soundmurderer/lib/x86_64/python2.6 I cannot set PYTHONHOME to point to this, because my path does not end in "lib/pythonX.Y". Of course, you could say that I should just move the Python libs, but it may create inconsistencies on how stuff is organized on some systems. PYTHONHOME should point to the Python installation root, period. Please give the admin complete control. Also, the --libdir flag to ./configure should work and set PYTHONHOME correctly. The fact that it does nothing has its own ticket, see: http://bugs.python.org/issue858809 It is, however, my humble opinion that fixing that other ticket properly also necessitates fixing how PYTHONHOME works (because --libdir should set the default PYTHONHOME during build/install), so they should really be one issue. Thanks! |
|
|
| msg88084 - (view) |
Author: R. David Murray (r.david.murray) *  |
Date: 2009-05-19 18:14 |
| PYTHONHOME is defined as 'prefix:exec-prefix'. Given that definition the library must be resolved relatively by appending 'lib/pythonX.Y'. Given the long standing nature of this interface, I doubt the meaning can be changed. It might be possible to _extend_ the definition of PYTHONHOME to have additional elements, one of which would be libdir. It seems to me that this would be backward compatible. This possibility, and/or other solutions, would be more appropriately discussed on python-ideas. And then of course someone would have to develop a patch to implement whatever scheme wins consensus (assuming the consensus is that this is a problem worth solving). |
|
|
| msg88229 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-05-23 11:21 |
| > PYTHONHOME should point to the Python installation root, period. And indeed, it does. After your proposed, changed, it wouldn't anymore. The Python installation root is *not* the directory where the Python library lives, but the parent directory in which both to find the python executable (bin/python), and the library (lib/pythonX.Y). As R. David Murray explains, there is no chance that this definition could possibly change - it would break existing systems. I'm not quite sure what you want to achieve: if you want an additional directory to show up in sys.path, just edit Modules/Setup. |
|
|
| msg88249 - (view) |
Author: (soundmurderer) |
Date: 2009-05-23 18:54 |
| OK, I'm convinced. Changing PYTHONHOME is bad. But I am all in favor R. David Murray's solution of extending to include something like PYTHONHOMELIB. Martin v. Löwis: What I want is simply to be able to use --libdir to tell ./configure where to put standard Python libs, and I want my Python installation to recognize this lib location without having to hack PYTHONPATH or PYTHONHOME or anything else. This would make the behavior of --libdir exactly what people generally expect from using configure scripts supplied by many other projects. As of now, setting --libdir doesn't even do anything, silently! But even fixing --libdir per patch in http://bugs.python.org/issue858809 still doesn't work because the lib path has a hardcoded component. I just think that a sys admin, when he/she sees a configure script, should be able to tell it what to do via flags, run it, and expect it to Do The Right Thing, without worrying about the Python-specific workarounds to make libs and bins go to the desired place. |
|
|
| msg88252 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2009-05-23 20:17 |
| > Martin v. Löwis: What I want is simply to be able to use --libdir to > tell ./configure where to put standard Python libs, and I want my Python > installation to recognize this lib location without having to hack > PYTHONPATH or PYTHONHOME or anything else. Ok. Then I shall close this report as "won't fix", because a) we cannot change the semantics of the environment variables easily, and b) changing environment variables doesn't solve your original problem. |
|
|