[Bf-committers] solving the issues of switching to python 2.4onOs
X for next release
jgilbert at tigr.ORG
Wed Aug 24 19:23:16 CEST 2005
Wanted to add something more to the discussion :0
There are also other modules that python may not be able to detect without a matching installation, outside of the 'user installed' modules. All modules that are not classified as 'built-ins' will not be detected unless a python installation is found.
In a typical python installation 'math' is considered a core built-in module (in 2.3) and will be found with the blender interpreter. However things like 'random' are not even though they come with a python installation. Therefore scripts that use non-'built-in' modules (even though they come with a default installation) will not be run when your unable to detect a python installation.
We might be able to get around this though. Currently the windows installer has a python23.zip file with many non-'builtin' modules included in it that the blender python interpreter loads (even without a python install). Also it might be able to statically build non-'builtin's into the interpreter through the _inittab (initialization table) internally so that the whole of python is available and not just the built-ins. This still leaves you 'high and dry' though with user installed modules.
Clearly having an installation that is detectable therefore is desirable. ;)
From: bf-committers-bounces at projects.blender.org [mailto:bf-committers-bounces at projects.blender.org] On Behalf Of Gilbert, Joseph
Sent: Wednesday, August 24, 2005 12:20 PM
To: bf-blender developers
Subject: RE: [Bf-committers] solving the issues of switching to python 2.4onOs X for next release
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).
Many users want the ability to access their 'user installed' modules. Which brings us to:
3. The site module detects a *version specific* /lib/site-packages directory. So, if you have python 2.3 installed with 'user installed' modules in that python installation and blender is running python 2.4 internally, it will not *see* the python 2.3 installation. Therefore, users can no longer access their 'user installed' modules, but can run python (and blender python) just fine. i.e. they will 'happily continue' :)
Why does this effect mac, irix (in particular) and some linux?
These OS's have 'officially' supported python distributions and apparently it is either difficult or impossible (on some versions of the mac OS -10.2 OSX and previous) to install a new(er) version of python.
Part of the issue here, is the fact that, python releases new versions fairly rapidly and the OS's that have 'officially supported' versions lag behind in their support. An example is the fact that osx tiger just released with python 2.3.5 as its supported version. It will be much later in the year or 2006 before support is official for python 2.4 for osx tiger. (Probably never in the case of older osx versions) However, it's likely that python will have moved on to 2.5 by then.
This is an issue likely to reappear when python 2.5 is released. Windows users and those on linux that have moved on will want blender to support the newer, better interpreter. Those with 'offical' python versions bundled into their OS (like osx) will want blender to support old(er) versions of python.
There are a few options here:
1. Force blender to run a specific version of python (probably an older 'common denominator' version).
2. Split blender's python support to support different versions of python for different OS's. (blender python 2.3 for mac, blender python 2.4 for windows, maybe both for linux distros). This would require making all bundled scripts 2.3 (or common-denominator) compatible.
3. Find some technical way of making the interpreter run different versions of python. (I'm not sure this is even possible - although it's worth a shot).
Anyway that's the issue. ;)
BTW grtz if you've made it this far into this email!
From: bf-committers-bounces at projects.blender.org [mailto:bf-committers-bounces at projects.blender.org] On Behalf Of Ton Roosendaal
Sent: Wednesday, August 24, 2005 6:06 AM
To: bf-blender developers
Subject: Re: [Bf-committers] solving the issues of switching to python 2.4 onOs X for next release
Now I get confused & feel stupid!
First of all, if you upgrade a framework to a newer version, why would
you then need to recompile all applications that use it? That seems to
me conflicting with the whole concept of dynamic libraries...
Or simple said; if someone upgrades Python on their mac, why can't
Blender then use it? We link with Python, not with a specific
version... I hope. :)
On 23 Aug, 2005, at 21:34, Jean-Luc Peurière wrote:
> As said at previous meeting, I've investigated the options we have,
> now that the python team want to switch to python 2.4.
> So far we relied on the system framework (dynamic lib) for 10.3
> releases, while the 10.2 ones were build with a static lib coming from
> fink package system. 10.2 users cannot upgrade to python2.4 so we
> keep them as they are
> Apple has not released a python system lib at 2.4 level, and even if
> they should do it at some time, we have no planned date for that, so
> we have to make choices.
> So the options are :
> 1/ release 10.3/10.4 build with /library framework version of
> python2.4 and relabel 10.2 build as static
> This method means that persons using the framework build *must*
> install the package found on
> python.org or blender will crash.
> they get a full python install available anywhere, eg in a shell.
> If they dont want/cant install it, they must use the static
> python2.3 one which will run fine for base
> modules . users of this build can use a full python by installing
> it from fink. Past experiences proves
> that installing from fink is not an easy task for many Osxers, so
> i dont want to go back to fink for
> 10.3/10,4 build.
> this method has the big advantage of being the smallest binaries
> sizes and smallest amount of work
> for the platform-managers (that would be me and Ton ;) Installation
> of the package is very easy, and is
> future compatible (Apple upgrading its system framework wont mess
> ours). we can even provide the
> link on our own download page.
> 2/ alternatively i can package 2 dmgs, one including both blender and
> the python installer (7.5 Mb)
> 3/ release 10.3/10.4 build with full framework version of python2.4
> in blender bundle. this would increase
> quite a lot the size (at least 7.5 MB) and means a fair amount of
> work for me.
> You cannot use the python framework anywhere else, and to add a
> new python lib you must put it in
> the blender bundle. that means that if you have say 3 versions of
> blender, each has his own python.
> Quite an overhead ! Most of the modules shipped with the full
> python are of no use for us.
> 4/ release 10.3/10.4 build with minimum framework version of
> python2.4 in blender bundle. Here size
> overhead is ok but that means that some skilled pythoner will have
> to choose what are the modules
> that should get shipped.
> additionals modules can be installed by setting the correct
> environ vars. Unfortunately the method
> to do this is not easy for average user (it involves creating a dir
> which is invisible from the finder and/or
> use terminal)
> I would favor 1/ or 2/ but need your feedback on this.
> Bf-committers mailing list
> Bf-committers at projects.blender.org
Ton Roosendaal Blender Foundation ton at blender.org
Bf-committers mailing list
Bf-committers at projects.blender.org
Bf-committers mailing list
Bf-committers at projects.blender.org
More information about the Bf-committers