bpy.utils.register_class silently overrides existing classes with the same bl_idname #116370

New Issue

Andrej · 2023-12-20T08:14:49+01:00

Andrej commented

2023-12-20 08:14:49 +01:00

Any Blender version

Calling bpy.utils.register_class for two operators A and B with the same bl_idname causes operator B to be overridden by A without any warnings or errors -- we now have warnings since c5e2ec8a1a

Additionally A.unregister() is never called, so it's not really unregistered.

Which can be unsafe as two addons may have the same names for operators and in case of name collision the addon registered first will break silently / start behave unexpectedly. In case if override is intended then previous operator can be unregistered with bpy.utils.unregister_class.

import bpy

bl_info = {
    "name": "Example Addon",
    "author": "Your Name",
    "version": (1, 0),
    "blender": (2, 90, 0),
    "location": "Properties > Modifiers",
    "description": "",
    "warning": "",
    "category": "Modifiers",
}

class TestOperator1(bpy.types.Operator):
    bl_idname = "object.test_operator"
    bl_label = "Test Operator 1"
    bl_options = {"REGISTER", "UNDO"}

    def execute(self, context):
        self.report({"INFO"}, self.bl_label)
        return {"FINISHED"}

    @classmethod
    def register(self):
        print(f'register {self.bl_label}')

    @classmethod
    def unregister(self):
        print(f'unregister {self.bl_label}')

class TestOperator2(bpy.types.Operator):
    bl_idname = "object.test_operator"
    bl_label = "Test Operator 2"
    bl_options = {"REGISTER", "UNDO"}

    def execute(self, context):
        self.report({"INFO"}, "2")
        return {"FINISHED"}

    @classmethod
    def register(self):
        print(f'register {self.bl_label}')

    @classmethod
    def unregister(self):
        print(f'unregister {self.bl_label}')

def register():
    bpy.utils.register_class(TestOperator1)
    bpy.utils.register_class(TestOperator2)

if __name__ == "__main__":
    register()
    bpy.ops.object.test_operator() # Info: 2

Any Blender version Calling `bpy.utils.register_class` for two operators A and B with the same `bl_idname` causes operator B to be overridden by A without any warnings or errors -- we now have warnings since c5e2ec8a1af5ca2b8f1a3a35692f5b034c38b357 Additionally `A.unregister()` is never called, so it's not really unregistered. Which can be unsafe as two addons may have the same names for operators and in case of name collision the addon registered first will break silently / start behave unexpectedly. In case if override is intended then previous operator can be unregistered with `bpy.utils.unregister_class`. ```python import bpy bl_info = { "name": "Example Addon", "author": "Your Name", "version": (1, 0), "blender": (2, 90, 0), "location": "Properties > Modifiers", "description": "", "warning": "", "category": "Modifiers", } class TestOperator1(bpy.types.Operator): bl_idname = "object.test_operator" bl_label = "Test Operator 1" bl_options = {"REGISTER", "UNDO"} def execute(self, context): self.report({"INFO"}, self.bl_label) return {"FINISHED"} @classmethod def register(self): print(f'register {self.bl_label}') @classmethod def unregister(self): print(f'unregister {self.bl_label}') class TestOperator2(bpy.types.Operator): bl_idname = "object.test_operator" bl_label = "Test Operator 2" bl_options = {"REGISTER", "UNDO"} def execute(self, context): self.report({"INFO"}, "2") return {"FINISHED"} @classmethod def register(self): print(f'register {self.bl_label}') @classmethod def unregister(self): print(f'unregister {self.bl_label}') def register(): bpy.utils.register_class(TestOperator1) bpy.utils.register_class(TestOperator2) if __name__ == "__main__": register() bpy.ops.object.test_operator() # Info: 2 ```

Andrej added the

labels 2023-12-20 08:14:49 +01:00

Philipp Oeser commented

2023-12-20 09:40:36 +01:00

Can confirm the behavior.

Not sure though if this can be considered a bug, will quickly check if we could/should at least spit out a warning/error

Can confirm the behavior. Not sure though if this can be considered a bug, will quickly check if we could/should at least spit out a warning/error

Philipp Oeser added

and removed

labels 2023-12-20 09:40:52 +01:00

Philipp Oeser commented

2023-12-20 10:42:15 +01:00

OK, checked a bit and the behavior of unregistering previous found operators (keyconf-prefs, gizmos, add-on preferences, ... many types affected...) is intended behavior.

(for affected types, check /* Check if we have registered this in code)

However I think it makes sense to spit out a warning in these cases, will put up a PR for this shortly.

OK, checked a bit and the behavior of unregistering previous found operators (keyconf-prefs, gizmos, add-on preferences, ... many types affected...) is intended behavior. (for affected types, check `/* Check if we have registered this` in code) However I think it makes sense to spit out a warning in these cases, will put up a PR for this shortly.

👍 1

Philipp Oeser self-assigned this 2023-12-20 10:42:23 +01:00

Philipp Oeser commented

2023-12-20 10:56:11 +01:00

and A.unregister() is never called, so it's not really unregistered

Ah, still have to check on this one, looking at code this should actually happen I think

>and A.unregister() is never called, so it's not really unregistered Ah, still have to check on this one, looking at code this should actually happen I think

Philipp Oeser referenced this issue

2023-12-20 12:40:56 +01:00

Report when `register_class` overrides classes with the same bl_idname #116374

Philipp Oeser referenced this issue from a commit

2024-01-16 14:43:51 +01:00

Report when `register_class` overrides classes with the same bl_idname

Hans Goudey referenced this issue from a commit

2024-01-17 16:39:22 +01:00

Report when `register_class` overrides classes with the same bl_idname

Philipp Oeser commented

2024-03-27 14:35:44 +01:00

Will unassign (since it is not something I am planning to work on), however the unregister() issue still needs to be looked at

Will unassign (since it is not something I am planning to work on), however the `unregister()` issue still needs to be looked at

Philipp Oeser removed their assignment 2024-03-27 14:35:52 +01:00

Philipp Oeser added

and removed

labels 2024-03-27 14:35:59 +01:00

Pratik Borhade commented

2024-04-11 09:09:44 +02:00

Additionally A.unregister() is never called, so it's not really unregistered...Which can be unsafe as two addons may have the same names for operators

Hi, rna_Operator_unregister is called for the first operator. So two operators of same names will never exists: https://projects.blender.org/blender/blender/src/branch/main/source/blender/makesrna/intern/rna_wm.cc#L1569-L1578

Guess you're expecting the execution of unregister() fn defined in python, right? Not sure how this is handled, forwarding to devs for more info.

> Additionally A.unregister() is never called, so it's not really unregistered...Which can be unsafe as two addons may have the same names for operators Hi, `rna_Operator_unregister` is called for the first operator. So two operators of same names will never exists: https://projects.blender.org/blender/blender/src/branch/main/source/blender/makesrna/intern/rna_wm.cc#L1569-L1578 Guess you're expecting the execution of unregister() fn defined in python, right? Not sure how this is handled, forwarding to devs for more info.

👍 1

Pratik Borhade added

Status

Needs Info from Developers

and removed

Status

Needs Triage

labels 2024-04-11 09:09:57 +02:00

Sign in to join this conversation.