[Bf-committers] Removing auto registration

Sat Jan 22 17:24:39 CET 2011

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-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 22 Jan, 2011, at 16:24, Martin Poirier wrote:

> Hi Ton,
>
> I'll try to explain this as simply as possible.
>
> Registering python classes with the RNA system has to be done in a  
> specific order to solve dependency issues.
>
> Unregistering (when unloading) also has to be done in a specific  
> order (not the same, maybe not just reverse order).
>
> There are situations for which a good order isn't currently known  
> (theorically, on paper).
>
> This is the registration order problem.
>
>
> If we choose to go with manual registration, we have to solve that  
> problem and have very special guidelines for python programmers,  
> otherwise stuff will break.
>
> If we choose to go with automatic registration, we have to solve  
> that problem and then write code that applies that solution (if that  
> can't be done, at last resort, there could be a way to turn it off  
> in specific cases and have to do it manually).
>
> In either case, not solving the registration problem is a bad thing  
> and things will break.
>
> In my wiki pages, I've proposed a solution to the problem that seems  
> simple and can easily be applied to both automatic or manual  
> registration (it's a simple set of rules like: UI first, then  
> operators, then ...), all that's needed is for other people to  
> validate this.
>
> Again, regardless of what registration method we use, the order  
> problem has to be fixed (before we switched to automatic  
> registration, people use to shuffle stuff around until it appeared  
> to work, that's not a solution).
>
> Is that clear?
>
> Martin
>
> --- On Sat, 1/22/11, Ton Roosendaal <ton at blender.org> wrote:
>
>> From: Ton Roosendaal <ton at blender.org>
>> Subject: Re: [Bf-committers] Removing auto registration
>> To: "bf-blender developers" <bf-committers at blender.org>
>> Received: Saturday, January 22, 2011, 9:57 AM
>> Hi Martin,
>>
>> Not capable of grasping your discussions with Campbell on
>> this topic,
>> I proposed to ask arbitration by a third person who knows
>> this well.
>> We're all equally stubborn fallible humans you know, and
>> who's "right"
>> or "wrong" then is less relevant than just moving forward.
>> :)
>>
>> If you think Brecht has all information you want him to
>> know, let's go
>> for his advice.
>>
>> -Ton-
>>
>> ------------------------------------------------------------------------
>> Ton Roosendaal  Blender Foundation   ton at blender.org
>>   www.blender.org
>> Blender Institute   Entrepotdok 57A
>> 1018AD Amsterdam   The Netherlands
>>
>> On 17 Jan, 2011, at 14:20, Martin Poirier wrote:
>>
>>>
>>>
>>> --- On Mon, 1/17/11, Campbell Barton <ideasman42 at gmail.com>
>> wrote:
>>>
>>>> Agree panel order shouldn't be a
>>>> factor in this discussion, it should
>>>> be solved irrespective of registration so addons
>> panels can
>>>> be added in a logical order.
>>>
>>> Ideally, this should be done before going out of
>> beta.
>>>
>>>> Though I'm still for auto-registration removal
>> even if its
>>>> bug free,
>>>> most likely re-iterating from previous mails.
>>>
>>> It's not so much the reiteration of your same
>> arguments that bugs me
>>> but the fact that you've completely ignored the
>> problems with the
>>> registration order and properties registration that
>> I've highlighted
>>> many times and that has to be dealt with regardless of
>> the
>>> registration method if we want to correctly and
>> cleanly handle
>>> enabling and disabling addons (which you seem to think
>> is an
>>> argument for manual registration but is completely
>> irrelevant).
>>>
>>>> - to me it feels mysterious that blender is
>> operating on
>>>> classes
>>>> without being asked & errors don't trace back
>> to
>>>> authors code.
>>>
>>> The traceback issue can be fixed quite simply. The
>> Metaclass has
>>> more info than manual registration on the class
>> definition itself
>>> (you can have the file and line where the class is
>> defined if that's
>>> what you want).
>>>
>>> As for blender operating on classes without being
>> asked, that's the
>>> whole point of inheritance.
>>>
>>>> - in simple cases where all classes are registered
>> its not
>>>> a big win
>>>> to have it automatic, in complicated cases of
>> dynamic
>>>> runtime registration this gets in the way.
>>>
>>> Yes, you did raise that point last time, it was bunk
>> back then too.
>>>
>>> Can you show an example of dynamic runtime
>> registration that deals
>>> correctly with registration order and unregistration
>> without making
>>> a truckload of assumptions or not working at all?
>>>
>>> Registration order is tightly coupled with internal
>> workings of
>>> Blender, exposing that to python is completely
>> ridiculous.
>>>
>>>> - it makes internals more complicated we need to
>> support -
>>>> 3 cases:
>>>> direct execution, modules and addons.
>>>
>>> There's only two cases, runtime execution and delayed
>> execution.
>>>
>>> Modules are addons that are registered automatically
>> after definition.
>>>
>>>> - 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.
>>>
>>> Didn't I addressed Nathan's issues last time?
>>>
>>> There's nothing about autoregistration that prevents
>> runtime
>>> definition of classes.
>>>
>>>> It is regrettable that I accepted this patch in
>> the first
>>>> place, but I
>>>> felt some obligation to do so since Martin
>> addressed the
>>>> issues that
>>>> concerned me, also because Brecht and Andria also
>> approved
>>>> of this
>>>> functionality at the time.
>>>
>>> It's regrettable that I tried to address the real
>> problems two
>>> months ago, after which you said you'd have to look
>> into it yourself
>>> and never came back until now, trying to force a
>> decision again.
>>>
>>> It's regrettable that you think autoregistration is an
>> opaque black
>>> box just because there's the word metaclass in there.
>>>
>>> But most of all, it's regrettable that you think
>> shoving that back
>>> in the ands of python developers will solve all
>> problems magically
>>> when in fact it means having to write more
>> documentation with
>>> warnings all over the place about proper registration
>> order.
>>>
>>> Martin
>>>
>>>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>