"James C. Ahlstrom" wrote:
Christian Tismer wrote:
I'd say we write a startup program which sits in the same directory as the python15.dll (which is the Python directory for my customers! I don't want to interfere with anything.) This extracts it's executable's program path, chdirs to there, sets the environment internally to "." (which holds now), and the site.py trick always should work.
We would need to remember the original getcwd() and chdir back so the user's "Start in" setting still works.
Well, that's easy. Whatever directory the user "was in", the path of the executable (i.e. what's in sys.executable) will be allways enough to figure out where you are now. This might not be a full path but a relative one, and it might (will) be the "short" version under Win9X, but anyway it was enough for the exec launcher to launch the .exe.
Also, I think it would be better to use the directory of python15.dll, since all of Python is in it, and that is where imports are done. It is not really a feature of the app.
In my case, python15.dll and python.exe *are* in the same directory. This is not the app, app.py is a file on top of this python directory, which is like plug-in (drop-in) and always the same. *int* the same python drop-in-dir I also have the simplified site.py which just takes care that the path settings are completed, that application scripts are found (by reaching out, off the directory, into app.py) and imports are prepended to ./lib stuff.
Works fine, regardless where ther is another Python installation, even if another one is running.
ciao - chris