[Bf-committers] Python API breakage - squeaking wheels

Matt Ebb matt at mke3.net
Mon May 27 15:34:32 CEST 2013


I suspect I'm one of the people Ton is mentioning so I'll say a quick word
here. These days at least for me, trying to work on an addon is frustrating
and demotivating, and the number one cause of it is API instability.

Maybe this is just something personal to my situation because I don't have
a lot of time for this sort of thing these days but for the last several
months the pattern has been something like: "ah I have some time on a
Sunday afternoon, why not do a few improvements and make some more progress
on the addon". So I update blender, and spend all the time I have available
testing and hunting through commit logs and googling just trying to make
the damn thing work again, without doing any creative/productive work of my
own. Next time around, it's the same pattern over and over again. So these
days there's little motivation to spend my free time finishing off the
remaining last round of fixes, let alone updating to fix the next. It seems
somehow acceptable now that scripts have to be updated every few months,
because as long as people change addons that are included in SVN then
there's no problem, right? Too bad if you don't want to work that way, or
have custom/proprietary tools.

To answer what kind of changes cause problems, *every* change is a
potential breakage and can make the difference in the eyes of a
user between an addon that works and an addon that doesn't. As I've
mentioned in the past, imo theres much too low a priority given to api
stability.

Looking at those pages previously linked (better publicity for this would
probably help), there's all kinds of minor renaming that all will break a
script that is using it. Having consistent names for properties can be a
nice hint as an aid to API users but constantly renaming things erases all
minor benefits and just makes life difficult. I was also pretty astounded
previously to have to update all of the template list calls, an absolutely
fundamental ui function, which apparently could not have been implemented
as a separate function or optional arguments? These sorts of changes would
never happen in any other app I use with a scripting API.

In specific one thing that I now have to fix is a bizarre error that's
never happened before, has cropped up in the last couple of months and
doesn't seem to show up in other examples included in blender,
like ArmatureButtonsPanel. [1]

Anyway, I know this could sound quite self centred. It's really not meant
to be, just a description of what a constantly changing API means to
someone in my position. If more time and effort is necessary to effectively
use blender's python API then I'm probably just not able to devote in the
requisite amount of time and energy, and I can accept that, and probably
won't much more. It's disappointing though.

Hope that provided some of the background you were looking for.

cheers

Matt


[1] https://github.com/mattebb/3delightblender/blob/master/ui.py
bpy.utils.register_module(): failed to registering class <class
'3delightblender.ui.InlineRibPanel'>
Traceback (most recent call last):
  File "bin/blender.app/Contents/MacOS/2.67/scripts/modules/bpy/utils.py",
line 578, in register_module
    register_class(cls)
AttributeError: expected Panel, InlineRibPanel class to have an "draw"
attribute



On Mon, May 27, 2013 at 1:50 AM, Campbell Barton <ideasman42 at gmail.com>wrote:

> Id like to hear what API changes cause problems.
>
> * if its one large change that causes problems for every one using the
> api (bmesh, pynodes)
> * if its misc changes in blender which propagate down into the api -
> (recent premul/alpha changes).
> * if its from being strict and adding limits like the restricted
> context, or disallowing data editing during drawing. (things that
> shouldn't be done anyway).
> * if its even intentional/known-about - Some end up being side effects
> of other changes in blender.
>
> On Sun, May 26, 2013 at 10:59 PM, Ton Roosendaal <ton at blender.org> wrote:
> > Hi,
> >
> > Excellent, we do have a API change page :)
> > http://wiki.blender.org/index.php/Extensions:2.6/Py/API_Changes
> >
> > Should get more prominent linking everywhere!
> >
> > -Ton-
> >
> > --------------------------------------------------------
> > Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> > Chairman Blender Foundation - Producer Blender Institute
> > Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
> >
> >
> >
> > On 26 May, 2013, at 13:23, Ton Roosendaal wrote:
> >
> >> Hi all,
> >>
> >> This is probably just coincidentally, but just in past few days two
> quite visible py scripters moaned in public about API breakage, more or
> less mentioning to give up on it.
> >>
> >> Communication is really King here. That means for every release, a
> simple quick to find doc with API changes has to be available (or is there
> one?).
> >>
> >> We can also reconfirm the procedures for api changes, to go along our
> release cycle:
> >>
> >> - Announce in BCon1 or BCon2.
> >> - Add it in BCon2 latest.
> >> - Testing, feedback during BCon3 and BCon4.
> >>
> >> We also have a bf-python mailing list where these topics are valid to
> discuss. I think every API change should be a topic for review there as
> well. It probably is? :)
> >>
> >> I think by default scripters can expect the API to keep working.
> Checking back on the history of Python script breakage discussion here, it
> appeared the changes were more related to "keep a good quality and sane
> API". Our scripting API is also powerful, and if you find smart bypasses
> for undocumented or accidentally working features, things can get
> frustrated...
> >>
> >> If you depend on the API to keep working, please consider to join
> bf-python, and help us out with reviews and design decisions!
> >>
> >> Thanks,
> >>
> >> -Ton-
> >>
> >> --------------------------------------------------------
> >> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> >> Chairman Blender Foundation - Producer Blender Institute
> >> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
> >>
> >>
> >>
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
>
>
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list