[Bf-committers] solving the issues of switching to python 2.4
onOs X for next release
jgilbert at TIGR.org
Wed Aug 24 23:37:00 CEST 2005
Jean-Luc Peurière wrote:
> Le 24 août 05, à 18:20, Gilbert, Joseph a écrit :
> Just to make things a bit murkier, what you said is true of all
> systems, except Os X 10.3 and above.
> Os X 10.2 build follow this scheme and python is indeed embedded at
> compilation. the only difficult thing is to define where the 'site'
> module is, if you want to use more than the core install. it involves
> setting an environment var for the finder (PYTHONPATH) which, AFAIK,
> can only be done by creating an xml file in an hidden directory.
The site module will reside in the embedded interpreter (it really is
defined in the dynamic python library that ships with blender and is
called from inside blender python). It's job it to add modules found in
/lib/site-packages to the sys.path list. The sys.path is your search
path for modules. Your PYTHONPATH will allow you to also add paths to
modules not installed in /lib/site-packages. e.g.
PYTHONPATH=C:\my_experimental_modules. This will add this path to
sys.path variable. I guess you could add ../python23/lib/site-packages
to your PYTHONPATH and that will probably load installed modules into
2.4 :) Setting an enviornmental variable for some reason seems *highly*
confusing to people - lol i dont know y.
> This proved in the past to be entirely too difficult for most OsXers,
> which are among the least technical of our users. Os X 10.2 build can
> be used on 10.3 and 10.4 systems without problem.
> So with this build (python 2.3), all users have a running version of
> blender but have difficulties to install more modules.
> For Os X 10.3 and 10.4 we used the official 2.3 framework which is
> guaranteed to be there. Framework are Mach O dynamic libraries.
> Problem is that Os X linker do not allow to statically link (embed) a
> framework, or at least i dont know how (and i searched). So on those
> systems, python was (is) fully dynamic, and not embedded in blender,
> but loaded as start like other dynamic libs.
> 'site' module being defined by the system, there was no problem on
> this side.
Yea, python doesnt statically link easy. It's built to be run from a
dynamic library. Our current versions link dynamically to a .dll (on
windows at least). The intrepreter is run from the dynamic library
shipped with blender (rather than the one in your python installation).
> Python2.4 framework is not an upgrade to the existing one, but a new
> framework which is not put in system but in /library. Being a
> different major number, 2.3 and 2.4 cannot be swapped at will at run
> time, but only at compilation. installation is easy.
> Apps on Os X can put in their bundle (which is essentially a dir) the
> frameworks they need, this is the 4/ point i proposed, but we get back
> to the previous problem of defining the 'site' module. Defining a core
> set of modules to ship with would allow to run all major scripts, that
> is what I requested.
I think we could define a set of core modules to force into the
'built-ins' like what windows does with it's python23.zip file. This
should allow users to use everything a python install would have to
> Bf-committers mailing list
> Bf-committers at projects.blender.org
I don't know - is this possible then? Can we include a full set of
python modules into the interpreter like what we have added for windows?
Possibly if people want to use 'user installed' modules installed in
python2.3 they could set a python path to
.../python23/lib/site-packages/xxx or whereever they have them
installed. Tell me if out in left field here :) It would seem like this
might solve alot of the difficulties here. (other than the enviornment
More information about the Bf-committers