Hi,
--- Andreas Raab andreas.raab@gmx.de wrote:
- 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.
- 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.
- 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