[Bf-committers] Moving to Python 3.2.x

Campbell Barton ideasman42 at gmail.com
Wed Mar 9 04:24:38 CET 2011


On Wed, Mar 9, 2011 at 1:45 AM, Richard Shaw <hobbes1069 at gmail.com> wrote:
> On Tue, Mar 8, 2011 at 6:13 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
>> We can upgrade python without causing too much inconvenience just be
>> ensuring we document how to install the latest python.
>> I thought that documenting how to build python would be enough, but it
>> seems us bearded linux geeks who like to compile blender from source
>> are for some reason not ok about building python.
>> ok, we can include instructions for getting python testing packages too.
>
> I'm only speaking for myself (though I *think* Dave P. would agree with me)...
>
> The problem is not that I'm personally against compiling python for my
> own use. The problem is that I'm trying to create and maintain a
> distributable package for a specific linux distribution that does not
> ***and will not have*** python 3.2 available to normal users who don't
> compile things for themselves.
>
> I am not saying that there were not good reasons for going to 3.2, I
> just wanted to clarify, at least for myself, why it's a problem.
>
> Respectfully,
> Richard M. Shaw

blender.org only supports official builds which are generally self
contained builds with static libs.

package builds use different flags, have patches applied and in the
past at least we didn't support these, not sure if this still applies.
eg: Gentoo package used to enable the YESIAMSTUPID define for
unsupported 64bit linux :)

Package maintainers could build with python 3.2, enable
WITH_PYTHON_INSTALL & voila the package will contain python 3.2 too.
Of-course this is not the gnu/debian way which prefers shared libs
where-ever possible.

Debian even discussed dropping blender because of this:
http://lists.debian.org/debian-devel/2009/08/msg00088.html

Not an excuse to make it hard for package maintainers, just to put
this in context that blender has been doing things `not the linux way`
for a while now.

Only supporting a single version of python IMHO is important to reduce
overhead with a small developer team,
for a while I was making sure python 2.6, 3.0, 3.1 all worked but it
just took time.

Granted py3.1-3.2 is nowhere near the same amount of API changes and
I'm ok to support both for some transitional period but not
continuously - we did this with blender 2.4x - py2.3/4/5, where we got
irritating breakages because of version incompatibilities, I had to
have all python versions installed and remember what features were
available in 2.3x so as not to use.

My impression is that if we only support 1 python version there will
always be Linux distros that are behind or ahead whatever python we
choose wont be supported.
Ofcourse we can hold back on upgrading at all as Matt suggests but
then its frustrating not to be able to use an updated python with
fixes on other OS's just because of Linux (which make up some small %
of blenders userbase, Ton has numbers)

For some background info this is the original thread about bundling python.
http://lists.blender.org/pipermail/bf-committers/2008-December/022277.html

Since blender is not stable yet, I think its reasonable to target
Fedora 15 & Ubuntu (Natty) which will have py3.2.


More information about the Bf-committers mailing list