using a private embedded python

Bryan belred1 at yahoo.com
Mon Mar 31 08:46:25 EST 2003


since PYTHONPATH is an environment variable i can modify it in my process
before PyInitialize, right?  so i think this won't be a problem.  does
PYTHONPATH change were the core libs are?  i've used PYTHONPATH to add
additional paths before, but not to change where the core paths are such as
lib, dll, site-packages, etc.

freeze sounds like a great idea especially since it's cross-platform.  my
concern is what you mentioned...,  that other company products will want to
use python or the python scripts i'm executing will want a module i haven't
frozen.   so this option unfortunately seems too restrictive.

to get a static version of python, i'll have to build it myself, since the
normal distribution doesn't come with it, right?  so, why would changing all
the environment variables and registry entries be bad? i could change
everything to PYTHONPATH_COMPANY.  and the registry to
HKLM/Software/Company/Python.  maybe still use the python22 shared library
but call it python_company instead too.

this is starting to be more of a pain than i had originally thought.

bryan


"Martin v. Löwis" <martin.vonloewis at hpi.uni-potsdam.de> wrote in message
news:b693js$jos$1 at zeppelin.rz.uni-potsdam.de...
> > 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