using a private embedded python

Martin v. Löwis martin.vonloewis at hpi.uni-potsdam.de
Mon Mar 31 05:00:27 EST 2003


> is there a common technique for embedding python with your application?

It depends on your requirements, and how much modifications to the
standard installation you allow/can accomodate.

> i
> need to guarantee product stability and since python is completely open,
> anyone can build their own version or install multiple versions, or
beta's,
> etc..  so, i'm forced to have our own verson of python installed in our
own
> private location.  if the end user wants to install python2.3a3 so be it,
> our product must run on 2.2.2 which our QA department as validated with
our
> product.  than means on windows, it'll probably end up being in program
> files/common files/<company>/python and moving the python22.dll from the
> windows directory there too.

Notice that people could still interfere with such an installation, e.g. by
setting PYTHONPATH, or adding registry keys.

> on unix maybe it's playing around with
> symlinks?

On Unix, you will typically link with libpythonxy. I recommend that you
use the static library (libpythonxy.a), not any shared library your
installation
may have. That way, your application becomes stand-alone with respect
to core object files.

If you want to become stand-alone with respect to the Python library
as well, I recommend to use freeze.

The same approach (freeze) works on Windows: You can arrange not
to have to rely on pythonxy.dll, but instead link all of Python statically.

> my question is how can i guarantee that from PyInitialize() to
> PyFinalize() will use this private version?

If you link statically, then you have an absolute guarantee. If you link
dynamically, you have to make sure you understand the search mechanism
of the operating system; the user can then defeat this mechanism by
removing the shared library; on Unix, setting LD_LIBRARY_PATH
may also have effects.

> do i have to build a version of
> python22.dll that doesn't (on windows) look in the registry but is hard
> coded to another location?  or should i modify sys.path to include only
our
> python build area?

If you are concerned about these things, I really recommend to use freeze.
Python will always look in the frozen modules first, so if you arrange to
freeze
any module you will ever use, sys.path and the registry become irrelevant.

HTH,
Martin






More information about the Python-list mailing list