[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