PYTHONPATH

Started by
4 comments, last by WazzatMan 14 years, 10 months ago
I'm trying to create a standalone python executable... it turned out to be pretty painless. I just compiled the following C++ code and copied the lib folder into the IDE's debug folder (Cleaning up the modules I don't need comes later :)).

#include <Python.h>

int main()
{

    Py_Initialize();

    PyRun_SimpleString("execfile(\"main.py\")");

    Py_Finalize();

    return 0;
}
contents of main.py:

import numpy

print("Hello World")
When I rename the folder where the default python interpreter's libraries are, the program still works. When I copy this executable, along with the file, the lib folder, and the python dll, to another machine without python installed, it works. I don't even get the "'import site' failed" error. The problem comes when I rename the lib folder inside the debug directory. The problem is that the program still works. Which leads me to believe that either the python dll searches for it's libraries in the PYTHONPATH first, and then the lib folder in it's directory, or vice versa. This is a bit iffy. Can I constrain the executable from searching in PYTHONPATH?
Advertisement
Did you try modifying sys.path?
... >_>

Now I did, and it worked, thanks :).

EDIT: A bit of experimentation (Displaying the contents of sys.path while both folders are properly named) actually reveals that Python looks in the current directory before looking up PYTHONPATH. In the end, this was a really stupid question.

[Edited by - WazzatMan on June 3, 2009 3:21:56 PM]
Quote:Original post by WazzatMan
I'm trying to create a standalone python executable...

py2exe?
Python's path searching is a bit awful actually. It goes through your current directory, some 'well-known' directories, the environment variable, the registry, you name it, it looks there. If you're not careful you can end up running a script against some other installation of Python on your system, or a Python dll in the system directory, etc.

Sadly I can't find the Google Groups post that explained all this to me. However, in moments of extreme confusion it can be useful to fire up Process Monitor to see which directories your executable is accessing to find the libraries.
Quote:py2exe [www.py2exe.org]


I know, I know.

But if you don't set it right, it creates a bit of a mess with some libraries, and it's been buggy with me when I used numpy. I also have no idea why it creates both an archive, and copies of the py files, and relies on BOTH!. So I thought it better to actually learn how to do it myself.

Quote:Python's path searching is a bit awful actually. It goes through your current directory, some 'well-known' directories, the environment variable, the registry, you name it, it looks there. If you're not careful you can end up running a script against some other installation of Python on your system, or a Python dll in the system directory, etc.


I kept the folder that PYTHONPATH points to intact. And then I copied the immediate .pyc files of the lib folder (But none of the sub folders) to a new lib folder inside the program's debug directory.

Sure enough, sys.path still pointed to the executable's current folder, and it couldn't find numpy. If it continued to search by using PYTHONPATH, it would have.

It seems python will basically stop searching once it finds these particular files. Fair enough, since they're probably Python's standard library. At least it always seems to start with the current folder.

Btw I got the 'site' error :). When I copied all the subfolders, I didn't, so obviously the file it needs is in one of them.

I know this seems like a lot of trouble to go to, but it gives me a nice clean bare bones Python that I can build on as I see fit.

EDIT: This was all done on a Windows OS. I still have to test it on Linux.

EDIT: Python seems to need the folder "lib\encodings" in order to get rid of the 'site' error.

[Edited by - WazzatMan on June 4, 2009 11:49:05 AM]

This topic is closed to new replies.

Advertisement