[Bf-committers] Failing addons/module load tests

[Campbell Barton]

New code in master checks for naming collisions.
Without this check bpy.types.* isn't a reliable way to access
registered classes.

Previously duplicates were silently ignored, it mostly worked out OK
since classes registered later never shadowed existing ones (so you
couldn't cause access to bpy.types.Menu/Operator/Panel... etc to
provide your own classes).

On Mon, Aug 28, 2017 at 6:00 PM, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
> Hi,
>
> Here is situation: in current master script_load_addons
> and script_load_modules tests are failing. Report says it's due to attempt
> to register class twice.
>
> For example, in archimesh, ObjectProperties is registered from door,
> venetian and window maker. This seems to be simple to solve: just
> rename ObjectProperties to {Door, Venetian, Window}ObjectProperties. Is it
> really a correct way of solving the issue?
>
> But then, some addons are registering operators with quite generic names,
> for example Splint in mesh_extra tools. Shall we just rename the class?
>
> Other thing whicvh is failing is io_coat3d, but that one i didn't figure
> out yet why exactly, code seems fine to me. Need someone's else eyes here.
>
> So., questions goes are:
> - Are my findings are correct about root cause of the failures?
> - Why this didn't fail before? Was it just a dangerous code which was
> allowing to override registered classes?
> - Shall we just rename some classes for now, so there are no conflicts?
>
> But bigger question is: how to avoid naming conflicts ins the future?
> Especially for addons which are not distributed with Blender?
>
> --
> With best regards, Sergey Sharybin
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell