[Bf-committers] Removing auto registration

Campbell Barton ideasman42 at gmail.com
Mon Jan 24 15:56:14 CET 2011


Martin correctly reprimanded me for being vague on the kinds of
problems that auto-registration causes, so I had a look into it today
:)

Started by looking into a registration bug in the tracker by removing
auto-registration locally to check if this was causing the problem.

https://projects.blender.org/tracker/index.php?func=detail&aid=24132&group_id=9&atid=498
https://projects.blender.org/tracker/?func=detail&aid=24498&group_id=9&atid=498
(the same bug but wasn't obvious initially)

In short, it is.
Any subclass of an IDPropertyGroup is instantly registered and never
unregistered, but this was a known problem.

If we remove auto registration editing existing addons to correctly
load/unload is not a big problem, I did one script as a test.
Though Martins answer is to fix the auto-registration which is all
very well, except that I still would rather remove it.

The other things are things are less immediately useful. For example
registering operators automatically, and removing them at runtime
while the script stays running.
How would this be done with the current system?, from what I can tell
it cant be.

@Marin, I think you misrepresent my position in one respect, You say
that I would have users solve registration problems themselves. This
isn't true, we can have a function which does a smart register of all
classes defined. I'm just against this being built into the class.

Infact when removing auto registration I added a utility to register
all classes in a module because defining class lists is tedious (as we
had before auto-registration was introduced).

def register():
    bpy.utils.auto_register(globals())

This registers all classes defined in that module, scanning globals is
ugly but I think we can get a good brief function and avoid class
lists.

So I don't think this should be seen as a choice between
automatic+clear OR bloilerplate+verbose.
For scripts which register every class like UI scripts we can have a
single function, nicer then having to define a class list.
Such a function could of course be extended to do dependency calculation too.

Btw, you mention finding the class line in python for errors, python
cant know where a class is defined, its just not stored. pythons
'inspect' module just a regex search on the source to find the most
likely match, not useful for blender internal texts.


- Campbell

On Sat, Jan 22, 2011 at 10:56 PM, Sergey Kurdakov
<sergey.forum at gmail.com> wrote:
> Hi,
>
> I'm sorry, as actually I would need to dig into details to understand all
> the subtleties,
> but few sparse thoughts
>
> order:
> is it possible to have a two step registration? such that first - there  map
> is created ( or graph
> http://www.boost.org/doc/libs/1_45_0/libs/graph/doc/index.html )  like it is
> done in boost.python (starting files  to look at
> are \boost\python\converter\registry.hpp
> | boost\python\converter\registrations.hpp  )  of types ,
> where all requested types are registered upon class creation and then
> then the whole system is glued together ( registered ) looking for
> unavailable parts and the next step?
>
> will it solve
>> Matt Ebb and Nathan Vegdahl have complained about auto-registration
>>in its current state fir renderman support which does dynamic
>>generated classes from shaders, and rigify for rig types.
>
> if yes. then why two step registration is not an option ( or will it add too
> much complexity)?
>
> Regards
> Sergey
> _______________________________________________
> 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