Hi Leonardo, On 03/19/2011 08:18 PM, Leonardo Rochael Almeida wrote: > Another variant of this case, one we're actually facing here at our > company (Nexedi) right now, is when you need to compile extension > modules with libraries that are newer than the ones in the system, and > you don't have root access. The absense of LD_LIBRARY_PATH means a > segfault on an arbitrary moment during execution, not just an > unloadable library.
Hmm. So my design goal for pythonv is that it "just work" to the same extent a real installation of Python would. IIUC in this case even if you were compiling your own full installation of Python, you would still need to manually set LD_LIBRARY_PATH to ensure that your newer shared libraries would be found before the system ones. So I don't think pythonv would change anything here. To be clear, pythonv is not going to _prevent_ anyone from setting LD_LIBRARY_PATH before running the virtualized python. The open question is whether pythonv needs to automatically and transparently set LD_LIBRARY_PATH to point to some location in the virtual environment every time you use it, in order to work as well as a normal installation of Python. Actually, the comparison to installing a custom-compiled Python to a non-standard location increases my sense that pythonv should not automatically add to LD_LIBRARY_PATH. If you "make install" Python to a non-standard location (on my Ubuntu system I have various versions of Python that I've compiled and installed in /opt), it doesn't take it upon itself to modify your system's library path accordingly, does it? So why should pythonv do any differently? Carl _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
