[Bf-committers] solving the issues of switching to python 2.4 onOs X for next release

[Jean-Luc Peurière]

Le 24 août 05, à 18:20, Gilbert, Joseph a écrit :

> Just want to help clear the murky waters here :) lol
>
> 1. Blender runs python internally.  It doesn't matter on what system 
> you're talking about. If we build blender with python 2.4 all systems 
> blender runs on will be running python 2.4. Regardless of whether this 
> is a mac, irix or windows. Python is run embedded inside of the 
> blender application with no need for a python installation. If python 
> is not found, it will 'happily continue'. :p
>
> 2. The #include <Python.h> headers are what compiles python into 
> blender. This is true for either static or dynamic linking (in which 
> case it looks for a specific .dll on windows at least - each version 
> of python has a separate dynamic library). The *path* to this header 
> determines the version of the interpreter that the blender application 
> will run (and concurrently which dynamic library to search for). If 
> the path is ../python24/ for instance than your embedded interpreter 
> will be a 2.4 interpreter.
>
> (None of the above is a problem :)
> So what's the problem?
> When python launches, it looks in a module (internal to python) called 
> 'site' which tries to locate a python installation on the computer 
> blender is running on. This 'site' module helps the embedded 
> interpreter detect a directory called /lib/site-packages/.  This 
> location is where 'user installed' python packages go.  E.g. you 
> install a numeric processing package into your installation of python 
> to help you with something and it ends up in 
> /python24/lib/site-packages (or into /python23/lib/site-packages).
>

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.

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.

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.