using a private embedded python

[Bryan]

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

"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
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
> >
> >
>
>