[Bf-committers] Python API breakage - squeaking wheels

Wed May 29 00:01:01 CEST 2013

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