[Bf-committers] Bundle Python 3.0 for Blender 2.5
ton at blender.org
Fri Dec 5 19:47:44 CET 2008
I think it's very important to stick to the smallest feasible
targets... thanks to work we do on fixing event/tools, we will have RNA
(data API) and Operators (tools API). These apis can be automatically
wrapped to python, or any language even.
However, there it stops for me. We wills still have a lot of calls in
Blender that are very useful for Blender as-a-tool, but not "a correct
API" or automatically wrapped. For that a more manual Python api is
still the best and quickest solution, think here of things like UI
stuff, managing certain data operations, etc.
Further, in my view Blender is not an Application Protocol Interface,
it's an artists' tool. The formentioned improvements (RNA, Operators)
are based on improving useful end-user specs. Let's try to get that
realized first. :)
About the bundling: I'm all in for a binary without external
dependencies, something that installs with installation procedures.
Python scripts are based on enabling useful end-user features, and can
therefore be easily bound to a specific release of Python... provided
that release is stable, and expected to stay there for many years. We
can even stick to python 2.5, for that reason.
Of course I'm talking about releases we do, and the standard scripts.
Next to that (we can even release that too) versions that allow custom
python installs are well possible.
Ton Roosendaal Blender Foundation ton at blender.org www.blender.org
Blender Institute BV Entrepotdok 57A 1018AD Amsterdam The Netherlands
On 5 Dec, 2008, at 19:10, joe wrote:
> I second the part about the C API. We need to be careful we don't
> lock our API code into python.
> On Fri, Dec 5, 2008 at 9:25 AM, Chris Want <cwant at ualberta.ca> wrote:
>> Reading this thread, I become more agreeable to the suggestion
>> that Early Ehlinger made earlier (no pun intended). He suggested
>> that python scripting should be handled as an external plugin
>> that loads at run time. Then the problem of having builds of
>> blender for different python versions doesn't matter: just
>> have one blender build and distribute it with plugins for
>> the different python versions. This, of course, would be a
>> lot easier with a well thought out C API, which I believe should
>> be the first step before tackling python (as I've mentioned
>> I should also point out that bundling python with blender adds
>> extra complexity to Blender's plethora of build systems. The
>> example of FFMPEG is a poor one since not all build
>> systems support it, there are issues under windowa, the
>> scons system supports it by having the additional
>> requirement of having autoconf installed, and I have
>> recently seen mails on the list from our game engine developer
>> trying to change the FFMPEG sources in extern, to which
>> there are no replies from the official maintainer. This is
>> not a role model to follow.
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers