Reference/Release Notes/2.80/Python API/Addons

Blender 2.80: Addon API

Version Info

Make sure the "blender" key in the bl_info dictionary is set to (2, 80, 0) not (2, 8, 0) or (2, 79, 0)

Example: "blender": (2, 80, 0),

Otherwise, this error is reported:

Exception: Add-on 'ADDON_NAME' has not been upgraded to 2.8, ignoring

Registration

Module Registration

Module registration (bpy.utils.register_module) convenience function has been removed, since keeping track of this information adds unnecessary overhead.

Add-on's should assign their classes to a tuple or list and register/unregister them directly.

eg:

classes = (
    FooClass,
    BarClass,
    BazClass,
)

def register():
    from bpy.utils import register_class
    for cls in classes:
        register_class(cls)

def unregister():
    from bpy.utils import unregister_class
    for cls in reversed(classes):
        unregister_class(cls)

To avoid having to copy & paste the functions above, you can use bpy.utils.register_classes_factory utility function.

classes = (
    FooClass,
    BarClass,
    BazClass,
)
register, unregister = bpy.utils.register_classes_factory(classes)

If you have an addon with many classes, the list can be generated using this patch: https://developer.blender.org/P455

Class Registration

See T52599 for proposal and details.

Access (bpy.types)

Classes registered by addons are no longer available in bpy.types. Instead addons can import their own modules and access the classes directly.

However subclasses of [Header, Menu, Operator, Panel, UIList] remain accessible from bpy.types.

Naming

In Blender2.7x it was too easy to accidentally register multiple classes with the same name.

To prevent collisions 2.8x enforces naming conventions (already in use across much of Blender's code-base)

This constraint applies to the bl_idname of each class (or the class name which uses it if no bl_idname is defined in the class).

These are: UPPER_CASE_{SEPARATOR}_mixed_case, in the case of a menu the regular expression is:

   [A-Z][A-Z0-9_]*_MT_[A-Za-z0-9_]+

The separator for each class is listed below:

  • Header -> _HT_
  • Menu -> _MT_
  • Operator -> _OT_
  • Panel -> _PT_
  • UIList -> _UL_

Valid Examples:

  • OBJECT_OT_fancy_tool
  • SOME_HEADER_HT_my_header
  • PANEL123_PT_myPanel (lower case is preferred but mixed case is supported).

At the time of writing this, names that don't conform to this convention will produce a warning on startup. Eventually we will make this into an error, eg:

Warning: 'Oscurart Files Tools' doesn't contain '_PT_' with prefix & suffix
Warning: 'Oscurart Overrides' doesn't contain '_PT_' with prefix & suffix
Warning: 'Oscurart Animation Tools' doesn't contain '_PT_' with prefix & suffix

Class Property Registration

Classes that contain properties from bpy.props now use Python's type annotations (see PEP 526) and should be assigned using a single colon : in Blender 2.8x instead of equals = as was done in 2.7x:

2.7x:

class MyOperator(Operator):
    value = IntProperty()

2.8x:

class MyOperator(Operator):
    value: IntProperty()

Using the 2.7x syntax in 2.80 or later will result in this error:

Warning: class Foo "contains a properties which should be an annotation!"