using a private embedded python
belred1 at yahoo.com
Mon Mar 31 17:05:21 CEST 2003
here's another way to ask the same question... can you have two seperate
versions of 2.2.2 on the machine at the same time? on windows? on unix?
"Bryan" <belred1 at yahoo.com> wrote in message
news:REXha.316269$S_4.271878 at rwcrnsc53...
> 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
> 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
> use python or the python scripts i'm executing will want a module i
> 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
> 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.
> "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
> > 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
> > > 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
> > own
> > > private location. if the end user wants to install python2.3a3 so be
> > > our product must run on 2.2.2 which our QA department as validated
> > our
> > > product. than means on windows, it'll probably end up being in
> > > files/common files/<company>/python and moving the python22.dll from
> > > windows directory there too.
> > Notice that people could still interfere with such an installation, e.g.
> > 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
> > > 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
> > > coded to another location? or should i modify sys.path to include
> > our
> > > python build area?
> > If you are concerned about these things, I really recommend to use
> > Python will always look in the frozen modules first, so if you arrange
> > freeze
> > any module you will ever use, sys.path and the registry become
> > HTH,
> > Martin
More information about the Python-list