[Bf-committers] Python API breakage - squeaking wheels
Hi all, This is probably just coincidentally, but just in past few days two quite visible py scripters moaned in public about API breakage, more or less mentioning to give up on it. Communication is really King here. That means for every release, a simple quick to find doc with API changes has to be available (or is there one?). We can also reconfirm the procedures for api changes, to go along our release cycle: - Announce in BCon1 or BCon2. - Add it in BCon2 latest. - Testing, feedback during BCon3 and BCon4. We also have a bf-python mailing list where these topics are valid to discuss. I think every API change should be a topic for review there as well. It probably is? :) I think by default scripters can expect the API to keep working. Checking back on the history of Python script breakage discussion here, it appeared the changes were more related to "keep a good quality and sane API". Our scripting API is also powerful, and if you find smart bypasses for undocumented or accidentally working features, things can get frustrated... If you depend on the API to keep working, please consider to join bf-python, and help us out with reviews and design decisions! Thanks, -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Python API breakage - squeaking wheels
Hi, Excellent, we do have a API change page :) http://wiki.blender.org/index.php/Extensions:2.6/Py/API_Changes Should get more prominent linking everywhere! -Ton- Ton Roosendaal - t...@blender.org - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 26 May, 2013, at 13:23, Ton Roosendaal wrote: > Hi all, > > This is probably just coincidentally, but just in past few days two quite > visible py scripters moaned in public about API breakage, more or less > mentioning to give up on it. > > Communication is really King here. That means for every release, a simple > quick to find doc with API changes has to be available (or is there one?). > > We can also reconfirm the procedures for api changes, to go along our release > cycle: > > - Announce in BCon1 or BCon2. > - Add it in BCon2 latest. > - Testing, feedback during BCon3 and BCon4. > > We also have a bf-python mailing list where these topics are valid to > discuss. I think every API change should be a topic for review there as well. > It probably is? :) > > I think by default scripters can expect the API to keep working. Checking > back on the history of Python script breakage discussion here, it appeared > the changes were more related to "keep a good quality and sane API". Our > scripting API is also powerful, and if you find smart bypasses for > undocumented or accidentally working features, things can get frustrated... > > If you depend on the API to keep working, please consider to join bf-python, > and help us out with reviews and design decisions! > > Thanks, > > -Ton- > > > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation - Producer Blender Institute > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Python API breakage - squeaking wheels
Id like to hear what API changes cause problems. * if its one large change that causes problems for every one using the api (bmesh, pynodes) * if its misc changes in blender which propagate down into the api - (recent premul/alpha changes). * if its from being strict and adding limits like the restricted context, or disallowing data editing during drawing. (things that shouldn't be done anyway). * if its even intentional/known-about - Some end up being side effects of other changes in blender. On Sun, May 26, 2013 at 10:59 PM, Ton Roosendaal wrote: > Hi, > > Excellent, we do have a API change page :) > http://wiki.blender.org/index.php/Extensions:2.6/Py/API_Changes > > Should get more prominent linking everywhere! > > -Ton- > > > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation - Producer Blender Institute > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > On 26 May, 2013, at 13:23, Ton Roosendaal wrote: > >> Hi all, >> >> This is probably just coincidentally, but just in past few days two quite >> visible py scripters moaned in public about API breakage, more or less >> mentioning to give up on it. >> >> Communication is really King here. That means for every release, a simple >> quick to find doc with API changes has to be available (or is there one?). >> >> We can also reconfirm the procedures for api changes, to go along our >> release cycle: >> >> - Announce in BCon1 or BCon2. >> - Add it in BCon2 latest. >> - Testing, feedback during BCon3 and BCon4. >> >> We also have a bf-python mailing list where these topics are valid to >> discuss. I think every API change should be a topic for review there as >> well. It probably is? :) >> >> I think by default scripters can expect the API to keep working. Checking >> back on the history of Python script breakage discussion here, it appeared >> the changes were more related to "keep a good quality and sane API". Our >> scripting API is also powerful, and if you find smart bypasses for >> undocumented or accidentally working features, things can get frustrated... >> >> If you depend on the API to keep working, please consider to join bf-python, >> and help us out with reviews and design decisions! >> >> Thanks, >> >> -Ton- >> >> >> Ton Roosendaal - t...@blender.org - www.blender.org >> Chairman Blender Foundation - Producer Blender Institute >> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands >> >> >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Python API breakage - squeaking wheels
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 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 On Mon, May 27, 2013 at 1:50 AM, Campbell Barton wrote: > Id like to hear what API changes cause problems. > > * if its one large change that causes problems for every one using the > api (bmesh, pynodes) > * if its misc changes in blender which propagate down into the api - > (recent premul/alpha changes). > * if its from being strict and adding limits like the restricted > context, or disallowing data editing during drawing. (things that > shouldn't be done anyway). > * if its even intentional/known-about - Some end up being side effects > of other changes in blender. > > On Sun, May 26, 2013 at 10:59 PM, Ton Roosendaal wrote: > > Hi, > > > > Excellent, we do have a API change page :) > > http://wiki.blender.org/index.php/Extensions:2.6/Py/API_Changes > > > > Should get more prominent linking everywhere! > > > > -Ton- > > > > > > Ton Roosendaal - t...@blender.org - www.blender.org > > Chairman Blender Foundation - Producer Blender Institute > > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > > > > > On 26 May, 2013, at 13:23, Ton Roosendaal wrote: > > > >> Hi all, > >> > >> This is probably just coincidentally, but just in past few days two > quite visible py scripters moaned in public about API breakage, more or > less mentioning to give up on it. > >> > >> Communication is really King here. That means for every release, a > simple quick to find doc with API changes has to be available (or is there > one?). > >> > >> We can also reconfirm the procedures for api changes, to go along our > release cycle: > >> > >> - Announce in BCon1 or BCon2. > >> - Add it in BCon2 latest. > >> - Testing, feedback during BCon3 and BCon4. > >> > >> We also have
Re: [Bf-committers] Python API breakage - squeaking wheels
On Mon, May 27, 2013 at 11:34 PM, Matt Ebb 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 '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): ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Python API breakage - squeaking wheels
>> [1] https://github.com/mattebb/3delightblender/blob/master/ui.py >> bpy.utils.register_module(): failed to registering 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): Got the 3delight addon loading up ok. patch available here: https://github.com/mattebb/3delightblender/pull/5 >From the looks of it pynodes and ui-list updates in blender were the only significant api change that broke this. (both intentional changes/breakages to the API). -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Python API breakage - squeaking wheels
On Tue, May 28, 2013 at 1:32 AM, Campbell Barton wrote: >>> [1] https://github.com/mattebb/3delightblender/blob/master/ui.py >>> bpy.utils.register_module(): failed to registering 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): > > > Got the 3delight addon loading up ok. > patch available here: > https://github.com/mattebb/3delightblender/pull/5 > > From the looks of it pynodes and ui-list updates in blender were the > only significant api change that broke this. > (both intentional changes/breakages to the API). > > -- > - Campbell Follow up mail on this topic... >From what I can see the recent breakages that happened for Matt's 3delight addon were known and intentional (PyNodes & UI-List), We didn't do as good a job as we should of documenting these changes but from what I can see the breakages at least were not caused by 'constant renaming' or general carelessness on part of devs. 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. My conclusion is... - BMesh API updates broke (most/all) import export scripts, this annoyed users & devs giving a bad impression they don't forget quickly. - Some more recent breakage in areas of blender that were updated updated (PyNodes, image alpha changes) - at some point scripts will break if we change blender, hard to avoid. - Early on we did indeed make some big changes (addon info header name, registration, disabling editing settings while drawing) - There is one exception to my assertion that we have not been all that bad recently and thats the restriction of context access for addon startup, ... this did indeed break some scripts but this was really bad practice and I mainly did this because we kept getting complaints about 3rd party scripts crashing blender - and this was one of the main causes. When we do make API changes/breakages (which shouldn't happen often), just do a better job of documenting them, link to an example of how to update a script in release logs. If scripts do break I would prefer to know about it and have devs post on bf-python which is currently quite low traffic. But further I think we can continue development as we have been. -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Python API breakage - squeaking wheels
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)
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.
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
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.
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.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Python API breakage - squeaking wheels
>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
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@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
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
> 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@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Python API breakage - squeaking wheels
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?
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?
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.
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
JTa
From: Domino Marama
To: bf-blender developers
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
> 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 l
Re: [Bf-committers] Python API breakage - squeaking wheels
On Wed, May 29, 2013 at 4:06 AM, W. Nelson 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 > To: bf-blender developers > 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 >> 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 >
Re: [Bf-committers] Python API breakage - squeaking wheels
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 To: W. Nelson ; bf-blender developers 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 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 predic
