[Bf-committers] Python API breakage - squeaking wheels

Campbell Barton ideasman42 at gmail.com
Tue May 28 15:31:03 CEST 2013


>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:
> On 05/28/2013 11:26 AM, Campbell Barton wrote:
>> I still am a bit concerned that we get many complaints but very little
>> real evidence of the cause of addon breakage - just that it happens, I
>> realize not every project is opensource but enough are that links to
>> scripts that break would be very helpful for API devs.
>
> 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.

> I think the major problem is the changes such as these where the new way
> replaces the old way. I test against SVN builds so usually catch changes
> quickly and before my users do. But if I developed against release
> versions, then a new RC is the first time I'd be aware of issues. If I
> was on holiday, then it could even get to a release version and more
> users hitting problems before I got chance to do anything. Without a
> release or two with depreciated APIs it's something I need to constantly
> watch out and allow time for.

Its tricky and theres no perfect solution, suggest extension devs test
their addons with our beta/rc's.

> Things have been better the past few versions though. I've not needed to
> add any more svn checks since 2.65 - currently in this particular addon,
> there's over 20 checks to adjust for API changes but it does work on
> 2.59 to 2.67. For each version from 2.59 to 2.65 there is at least one
> check for the specific svn version to tweak things.
>
> While the majority of the changes are due to API improvements, sometimes
> they seem to be changes that maybe should have been reconsidered. One
> bit of my code walks over the edges of faces, so the only change needed was:
>
>     if svn <= 44243:
>         faces = mesh.faces
>     else:
>         faces = mesh.polygons

Keeping the attrubute ".faces" would have worked in trivial cases -
change material for example.
But would give more confusion in most cases since faces and polygons
are quite different.

> I am overdue for a code cleanup though. My official stance is that I
> support 3 older versions of Blender, so the majority of the svn checks
> are due for removal. For my first example, that results in the much nicer:
>
>         mesh = obj.data
>         uv_loops = mesh.uv_layers[uv_name].data
>         u_points = [v.uv.x for v in uv_loops]
>         v_points = [v.uv.y for v in uv_loops]
>
> So although the API breakage is a hassle, I do see the long term benefit
> to the changes.

As said before, these changes are tied to bmesh, long term benefit is
bmesh being much nicer mesh api.

> It's my choice to support multiple Blender versions rather than
> constantly recommending Blender updates as I get fewer requests for
> support that way :)
>
> Hope that helps clarify the issues API changes create and how I manage them.

It does but also confirms that BMesh was main offender (not sure you
were aware of this regarding UVs?).

> _______________________________________________
> 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