[Bf-committers] Removing auto registration

Bassam Kurdali bkurdali at freefactory.org
Sat Jan 22 19:23:54 CET 2011


a small comment if the core developers/ designers of the api can't
decide which way is 'right':
Don't change what's there. If there is controversy, it probably means
there are pros and cons both ways; any change comes with a cost- every
script has to be modified to work. In he case of stuff that ships with
blender, the py is compatible with the api, but it is a problem for
external developers; because now you have an incompatiblity between
betas/svn.
Even a simple change such as the change from bl_addon_info to bl_info
was a bit painful here, since we had to figure a way to keep addons
working for animators using betas, and for those of us who build svn (so
that we can get bug fixes early). It turned out to be a bit non trivial.
When we went to autoregistration , it was a couple days work cleaning
scripts, and get rid of setting attributes in autogenerated classes
(because they were now getting autoregistered) so code would work. We
still run into the occasional code path that has a 'register()' left
there that causes a script to raise an exception. Going back to
registration would cause similar havoc.

I'm not saying, don't do this if it's the right thing, but I am saying
it's useful to continue the discussion , and get a real consensus if the
problems can be solved. Cutting the gordions knot seems
counterproductive *if* things can be made to work cleanly.

to sum up my long winded argument :
"won't someone please think of the children" ;)
On Sat, 2011-01-22 at 17:24 +0100, Ton Roosendaal wrote:
> Hi,
> 
> Yes that sounds clean and clear. But apparently there's more ways to  
> solve the problem, and either way has pros and cons. When visions on  
> such problems don't align, then how to decide? The maintainers and  
> main contributors to the code then can have a final word.
> 
> -Ton-




More information about the Bf-committers mailing list