[Bf-committers] Removing auto registration

[Brecht Van Lommel]

Hi,

I don't really see the order problem as a problem we have to solve. If
you're registering multiple things, then it seems logical to me that
if A references B, you register B first and then A. It's not clear to
me where these potential complex rules would show up?

Brecht.

On Sat, Jan 22, 2011 at 5:33 PM, Martin Poirier <theeth at yahoo.com> wrote:
> Hi,
>
> The problem I have with taking a decision now is that we haven't solved the order problem.
>
> If it turns out to require very complex rules, it might be easier to solve automatically than manually (or vice versa).
>
> What I mean is that I don't think we have all the data to take a good decision at this point. Especially if correctly solving the problem means changes in the RNA api layer (it might), it would be better to start early (before the API is stabilized too much).
>
> 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, 11:24 AM
>> 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
>> >
>>
>> _______________________________________________
>> 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
>