Mathias Fröhlich added the comment: Hi Eric,
Thanks for looking at that ticket so fast! Reassigning this to 3.4 is great. In general, yes I can already do what I need more or less. This is the reason why I can be fine with about every python version. The point I bring up this change that I believe I am doing this at an unappropriate place as I need to know some internals of python when I do so and that I think that other can probably also benefit from this idea/change. What I currently do is to write an application that just uses python*.so as an embedded interpreter and this precompiled application might be relocated to about everywhere - just where it is unpacked. We are currently using the same sort of code to find out where the python*so file is and we use Py_SetPythonHome to set is to the directory where the so file resides. Why are we doing this? So, it takes the idea that is currently in the standard python interpreter. This one tries to be relocatable (means: pack the installation directory and unpack that somewhere else and be still able to run) by looking at argv[0] and dereferencing symbolic links until it arrives at a real file. Now suppose you want to embed python, then you do no longer use the standard python interpreter program. You may also use a different installation layout for basic things like bin and lib. So you end up with an application that is no longer able to find its provided python modules by looking at the applications path. But instead of starting from the path of the interpreter (which is not used in this case) or the application itself you could start from the python library path and look for your python installation relative to that. So as long as you stick with the relative file layout of everything that is python related (and only what is python related, the python.so and the modules) when you pack and unpack your precompiled application this would just work. So, put that in short: Instead of dynamically finding the the python module path relative to .../bin/python try to find the python relative to .../lib/libpython34.so. The benefit of that would be that every application that embeds python and needs to be relocatable will just work in the way that today only the standard python interpreter works. I try to get all of the PEP you pointed me to. As I am seeing this longer document the first time, I am not sure if I missed something there, but in that framework of this my proposal would probably influence the initial setting of sys.prefix (?) if this is not already provided from the embedding application. And yes I am perfectly fine with a different or more general approach. The initially attached patch is something that tried to integrate into the current checked in code as I understood it. Greetings Mathias ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18309> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
