[Bf-committers] Bundle Python 3.0 for Blender 2.5

[Campbell Barton]

On Sat, Dec 6, 2008 at 2:49 AM, Martin Poirier <theeth at yahoo.com> wrote:
>
>
>
> --- 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. ;)
By the time Blender2.5 is out it should be improved. bigger problems
fixed at least.

> 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)
People just want to download blender and start modeling, having to go
though extra steps is a chore, and it doesn't surprise me that many
users dont read the download page. (probably normal user behavior).

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

> * 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.
This list is a bit of an exaggeration, since we dont release blender
for 2.6 (yet), Nevertheless we DO need to keep scripts running on all
these versions of python, and the python API needs to compile with 4
versions of python still, so its not such an exaggeration.

> Heck, we could stick to a single version too, regardless of bundling.
Great :)
> * 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.
There were a few people who had trouble with ubuntu's python IIRC - It
had some customization that messed with blender.
> * 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?)
Just an example of a large library we include, but your right their
API stability is a reason we need to do this.
> * 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).
Uru, Battlefield 2, PaintShopPro and Openoffice were the apps I looked up.

> 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.
Yep, though the people with these problems were also having issues
running blender scripts. They are not just complaining about the
message.

> 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?

Im not familier with the import site wearning, Including modules
python scripts use is the main thing, the error is fine if their
scripts work. though I think if we give a propper module path with os,
sys, struct, CString math etc - these warnings will go away.

> 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.
Yep, this will only fix some of the problems, (I suspect many), Ill
mention this on the thread.

> Martin
>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell