[Bf-committers] Python API breakage - squeaking wheels

W. Nelson indigitalspace at yahoo.com
Thu May 30 19:12:37 CEST 2013


Thanks for your informative response and your time on this matter...the support of 3rd party devs is always appreciated.


Tracking down "real evidence" issues is outstanding work and very tangible, something that makes most things happen.   Addressing perception is much more challenging but it can have a positive effect on a few things happening...especially since perception frequently becomes reality for some people.  


Maybe I can add some "real evidence" to the perception facet.  Here's my flailing attempt since I don't think it is just the perception of only a few squeaky wheels.  I may have ante up'd to 4 cents from 2 cents of opinion with this so I will show my hand from the shuffle as I see it...


Quoted from below:
...

'> Maybe some variation on these ideas could be a good balance of progress and mitigating fails with predictability.

It sounds a bit like you are under the impression that a dev wakes up
in the morning and says - "I'm going to break the API, now is as good
a days as any" :), but infact this isnt how it happens (mostly),'...

The center of gravity that I am inferring is an improved predictability balance as in an ecological system.  The emphasis is on balance as much as predictability.

  

My college PolySci teacher, Frank Navarret spoke on the idea of people's interaction as an ecological system.  Asserting that something based on balances and predictability would help the ecology thrive.


Kwai Chang Caine, the famed 70's philosopher also mentioned balance and predictability quite a bit.  ; )

So my center of gravity and assertion is on balance as much as predictability.  The balance between the core values and goals of internal Blender work and the vantage point of 3rd party addon developers should be able to be improved with some simple adjustments to the current balancing point.  Something more proactive than reactive from this vantage point improves the return on investment of time.


I assume this year's SIGGraph will result in a few more prospective addon devs taking a look at Blender's platform ecology.  Time absorbing issues versus productive time, and what it will take for them to balance that, as has been stated, is one of the things they will consider.  Their perception of this balancing point being more in their favor from their vantage point will be important to attracting them and keeping current devs, IMHO.


So the core value of my assertion is shifting this balance point of awareness of upcoming changes more towards the 3rd party developers vantage point than it currently is.  Whether that means wiki page changes, the numbering or frequency changes I mentioned, or a specifically defined mailing list subject line that is IN ALL BOLD! ; ) or something more noticeable than the current balance point would work to improve the ecology, IMHO.  


The new wiki link added in March IIRC is an excellent example of this type of improvement.  Thanks to whoever added it.  From the root wiki page, two clicks away is "Blender Python API changes if you need to update your addon" and it contains the Restricted Context topic among others.  Yet, this is still a reactionary help, not a proactive help.  People are still getting surprised by this change as illustrated by the very question on it today in #blenderpython.  So any type of proactive help that will facilitate devs not getting so easily caught in this reactionary trap should increase the predictability balance point of the ecology.


So if anything can be done to shift that balance point more towards that of the 3rd party addon devs typical vantage point, I think it will improve the ecology of the Blender platform, give a better return on time investment and also attract more new devs, IMHO.

-=JTa=-


PS: okay, maybe 8 cents ;p



________________________________
 From: Campbell Barton <ideasman42 at gmail.com>
To: W. Nelson <indigitalspace at yahoo.com>; bf-blender developers <bf-committers at blender.org> 
Sent: Tuesday, May 28, 2013 3:01 PM
Subject: Re: [Bf-committers] Python API breakage - squeaking wheels
 

On Wed, May 29, 2013 at 4:06 AM, W. Nelson <indigitalspace at yahoo.com> wrote:
> Would some sort of scheduling updates to a specific date or version of Blender help alleviate a lot of the finding out after the fact issues that seem to be floating to the top of this conversation?

We have done this for planned API updates (deprecating game engine API
I think worked quite well some years back), with warnings giving line
number and letting dev know they used a deprecated features.

The reason I dont think this applies much to current projects we do is
that most breakages are not because we choose to update blenders API's
directly, but because we choose to improve blender, and API changes
are side effects of blenders internals working differently. This also
makes it hard/impossible to deprecate old behavior - its just blender
works differently and its very hard to predict when that breaks
scripts - of course any subtle change can always break a script. But I
think maintainers have an idea what changes will end up being very
disruptive.

This is just a tradeoff with the benefit of being able to access
pretty much everything in python.

> That would give time for looking at the upcoming change before it gets committed.  It could be proactively posted on a scheduled changes to py wiki page.  If there is not urgency to the change, then it would come at predictable or expected time frames.  This allows us 3rd party script developers to be proactive instead of reactive to changes.  Predictability even gives core development clear windows of opportunity.
>
>
> Something as universal to Blender as Python/scripting maybe could only be updated with specific version numbers or reduced to once or twice a year.
> Without throwing fuel on the versioning topic in general...maybe something like second digit changes and the 5 on third digit changes.
> EG:  py maintenance updates only on 2.70, 2.75, 2.80, 2.85...
>
> Or date changes could be used.  Only twice per year at most maybe?

This sounds good - but I really cant see it happening - say we have to
merge 10 google summer of code projects which make internal changes,
some of those changes influence API's - We barely can find enough devs
to do good code review + merge, let alone fit this into some kind of
API versioning scheme that also happens to fit with release cycles and
when the student has spare time to help with the merge,

> EG: February's nearest release after February 1st and July's nearest release after July 1st
>
>
> Maybe some variation on these ideas could be a good balance of progress and mitigating fails with predictability.

It sounds a bit like you are under the impression that a dev wakes up
in the morning and says - "I'm going to break the API, now is as good
a days as any" :), but infact this isnt how it happens (mostly),
take Depsgraph refactor thats planned (2 depsgraph GSOC projects
infact). Im going to guess this will break some python scripts, simply
because enough scripts rely on how blender updates data, and larger
changes to depsgraph may tweak this in a way scripts don't account for
- I may be wrong here, but it wouldnt surprise me if some scripts
break because of that.

So just because we cant have complete control doesn't mean we have to
accept disorganized chaos, but since we dont plan to make any breaking
changes in the foreseeable future (aside from projects that touch the
API indirectly), I don't think we need to put in place plans like
this.

> RECAP:
> Proposing ideas like-
>   flipping the reactionary coin to proactive side
>
>   scheduling updates to py for predictability
>
>   changes only on dates or specific version numbers
>
>   wiki page with upcoming changes

Your comments are quite reasonable but IMHO they would only apply...
- if we were a projects who's main purpose was to be a framework/api
for developers to interface.
- if we only exposed a very limited set of features to devs that we
could improve blender without having side effects in the API.

> JTa
>
>
>
>
> ________________________________
>  From: Domino Marama <domino at dominodesigns.info>
> To: bf-blender developers <bf-committers at blender.org>
> Sent: Tuesday, May 28, 2013 9:17 AM
> Subject: Re: [Bf-committers] Python API breakage - squeaking wheels
>
>
> On 05/28/2013 02:31 PM, Campbell Barton wrote:
>> >From your mail it looks like all changes you note were from bmesh
>> upgrade (except build_revision)
>>
>> On Tue, May 28, 2013 at 9:36 PM, Domino Marama
>> <domino at dominodesigns.info> wrote:
>>> For my scripts the changes to UV handling caused the most problems..
>>> Supporting multiple Blender versions from same script version results in
>>> code like this:
>>>
>>>         u_points = []
>>>         v_points = []
>>>         mesh = obj.data
>>>
>>>         if svn <= 44243:
>>>             for f in mesh.uv_textures[uv_name].data:
>>>                 for u, v in f.uv:
>>>                     u_points.append(u)
>>>                     v_points.append(v)
>>>         else:
>>>             if svn > 45996:
>>>                 uv_loops = mesh.uv_layers[uv_name].data
>>>             else:
>>>                 loopindex = mesh.uv_textures.keys().index(uv_name)
>>>                 uv_loops = mesh.uv_layers[loopindex].data
>>>             u_points = [v.uv.x for v in uv_loops]
>>>             v_points = [v.uv.y for v in uv_loops]
>>>
>>> And other changes mean I have to do this to get the svn version :)
>>>
>>>     try:
>>>         svn = bpy.app.build_revision.decode().split(':')[-1].rstrip('M')
>>>     except:
>>>         svn = bpy.app.build_revision.split(':')[-1].rstrip('M')
>>>     svn = int(svn)
>> This isn't totally reliable, some builds dont include buildinfo, Id
>> suggest using blender version rather then checking revisions.
>> Also moving to git - revisions will work differently too.
> Yeah I just posted that because of the irony in my routine for handling
> API changes being affected by them. I'm sure you see the additional
> irony in pointing out that it is going to break again in the future :)
>
> In the full code the svn = int(svn) line is in a try: except with a
> fallback of estimating a svn number from the Blender version. I had to
> do it this way as the Blender version isn't updated until release so
> when API breakages occur I need to be able to target specific commits to
> test against current builds
>> It does but also confirms that BMesh was main offender (not sure you
>> were aware of this regarding UVs?).
>>
> Yeah the majority of the the current switches in my code are bmesh
> related. I couldn't do a full switch to bmesh without losing backward
> compatibility, so it's mostly old API with just the UV handling from
> bmesh on newer versions. Now there's enough old versions with bmesh I
> can plan the full migration of the code to the new APIs.
>
> Prior to that the last big script shakeup was the switch to python3.
>
> I really posted as an example of a different way that script authors may
> be working. Assuming a new Blender release with API changes means that
> script authors will do new versions of their scripts makes work for
> people who may not have scheduled for it. Having a few releases where
> depreciated functions give warnings lets people schedule these things in
> rather than having to make it their main priority. For those of us who
> support older versions on same scripts, it also makes life a little
> easier as we could fall into synch with the depreciation cycle rather
> than having to work around things to keep compatibility.
> _______________________________________________
> 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


More information about the Bf-committers mailing list