[Bf-committers] Bundle Python 3.0 for Blender 2.5

[Martin Poirier]

--- On Fri, 12/5/08, Campbell Barton <ideasman42 at gmail.com> wrote:

> Its highly likely many/most? scripts will need to be
> modified to run
> in Blender2.5 - so having to do edits for py3 is minimal
> effort if
> your already updating your script for a new/modified api.
> It is a con, but comparatively not a huge one IMHO.
> especially if you
> consider we will move to py3 at some point anyway.

True, but I really don't think that point should be now (as in this very moment). For one thing, Py3K is just out of the door, as you said yourself in the BA thread, the first version of a rewrite is often not the most stable. ;)

2.50 is not going to be released any time soon and you said switching to Py3K means very little changes internally, so no need to rush that decision (at least not until the design of the API is fixed)

Regarding bundling, going over the *pro* list:

* We can include modules bundled scripts use so that users are not
faced with error messages when they try a python tool.

I guess that's a fix for users not reading the download page properly? (or the page not being precise enough about external dependency on Python)

If it's a problem with bundled script not having correct failsafe, then that's different altogether.

* No need to distribute blender for versions py 2.3, 2.4, 2.5, 2.6....
and later 3.0 - We already are having to do both 32 and 64bit Blender
builds. Many users wont know what python version is installed on their system.

We currently only have builds with 2.4 and 2.5 on the download page (or py 2.3 for os X, but they don't have 2.4 builds), so I don't quite see where you got your list. Moreover, if we decide to move to 3K, there's no way in hell that we'll be maintaining two sets of bundled script for backward compatibilities, so we can drop all 2.X versions then.

Heck, we could stick to a single version too, regardless of bundling.

* A reliable python means we can use it for more important aspects of Blender 2.5 (something Ton has suggested)

That, IMHO, should be the biggest argument.

* No conflicts with the system python - there have been bug reports
where the system python was crashing blender.

The one I remember (there might have been others mind you) was caused by a faulty compile (of Python or Blender, it wasn't clear) and couldn't be reproduced on other systems using the same distro.

* Blender already includes FFMpeg and some other significant libs on
most OS's

Comparing to ffmpeg is a bit loaded, their API is about as stable as a pile of rumble and they don't have released versions we can reliably link against (or did they finally bit that bullet?)

* Openoffice and some games include python, searched for python
problems with these apps and didnt find complaints, common with
Blender.

If you were thinking of EVE, they include Stackless Python, hardly comparable (moreover, we already bundle on windows).

The most frequent "complain" about Blender's Python is the site-package missing warning, if they disable import of external package, of course they wouldn't see that.

I have a couple of technical questions though. By bundling the interpreter and some libs but still leaving the possibility of importing external libs, won't this also leave us open to the same site-package incompatibilities/missing warning message that we currently have and that you seem to identify as "the big problem with not bundling python"? I mean, we already bundle Python on windows and most of the reports are on that OS, so how is that a fix?

I find the long list of BA threads somewhat disingenuous (have you even read them before posting?) as lots of them wouldn't be fixed with bundling Python (permission problem on Vista, wrong libc version, how to run multiple versions of blender, exception in a script at runtime, ...), but I digress. 

Martin