[Bf-committers] Python API breakage - squeaking wheels

[Campbell Barton]

On Mon, May 27, 2013 at 11:34 PM, Matt Ebb <matt at mke3.net> wrote:
> 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

Quick reply about this python exception, the problem here is that you
have a mix-in class that gets registered.
InlineRibPanel, checked with 2.62 and it has the same behavior (quite
sure its been this way for over a year).

So fix is to change:
class InlineRibPanel(CollectionPanel, bpy.types.Panel):
to...
class InlineRibPanel(CollectionPanel):