[capi-sig] Deploying embedded Python

[Martin Poirier]

Hi,

--- Andreas Raab <andreas.raab at gmx.de> wrote:

> 1) How to define a useful subset of the stdlib that
> can serve as an 
> initial basis for the installation but later allows
> upgrade to the 
> "full" library if desirable. In other words, I'd
> like to deploy a small 
> subset of the stdlib to begin with (simply because
> of size constraints) 
> which may later be extended to a full stdlib if this
> is desirable. Has 
> someone done this before? I'd love to have a small
> "Python.zip" 
> cross-platform stdlib surrogate that just gets
> shipped with the product. 
> If not, what is the right starting point for
> analyzing the dependencies 
> inside the stdlib?

We do that for windows version of Blender (
http://www.blender.org/ ) (other OSes are assumed to
have a full python distro already).

What we did to select the different modules included
was very arbitrary. We picked the minimal set of
modules that was required by scripts we wanted to ship
with Blender at this point. With passing releases, we
added some more, trying to keep size low (one of the
reasons we don't include the xml parsing modules,
IIRC).

Currently, this includes os (and its dependencies),
random, webbrowser, threading, struct, tokenize, ...

I really wouldn't recommend the method we used to get
dependency, which was (if memory serves right) a mix
of looking at the sources and trial/error on a test
machine, adding missing dependencies until it worked.

> 2) How to isolate the embedded interpreter from
> environmental effects. I 
> have found that on occasion, the interpreter would
> pick up "stray" 
> installations which can cause weird problems. Which
> environmental 
> settings affect the startup of an embedded Python
> interpreter? How does 
> one work around/remove those dependencies? Is there
> any information 
> available about how exactly the startup works? What
> is being read/loaded 
> in which order etc?

That's an excellent question. I'm not sure if we came
up with a viable solution for that problem either, so
if anybody else would like to pitch in an answer, we'd
appreciate too.

This particular problem causes much pain when people
have binary modules from older versions of Python in
their import paths.

> 3) General advice about deploying embedded Python.
> Pointers to web 
> sites, general experience (good or bad) etc. are all
> very welcome.

>From experience, unless you want to limit python input
to things included with the distribution of your
software, I'd say limit the included modules to the
bare minimum, otherwise it's easy to get to a point
where you're pretty much including the whole Python
distro anyway, so might as well ask your users to
install that directly.

I hope that was a bit helpful.

Martin
PS: Apologies to Andreas for the double post, I sent
my original email to you directly instead of the list,
as I intended.


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ