Combined Add-on Extensions

Documentation
1

Hello,
I’m trying to understand the documentation on the new Extensions system.

Bundle other add-ons together.

This is recommended if an add-on depends on another add-on.

Make sure that both the individual and the combined add-on check for already registered types (Operators, Panels, …). This avoids duplication of operators and panels on the interface if the add-ons are installed as a bundle and individually.

Could someone please clarify how a bundled extension might look, file structure-wise? How would we identify each individual add-on within a combined add-on bundle and how are they registered?

scripts/
└── addons/
    └── my_multi_addon/
        ├── __init__.py
        ├── AUTHORS
        ├── blender_manifest.toml
        ├── addon_one/
        │   ├── __init__.py
        │   ├── operators.py
        │   ├── panels.py
        │   └── utils.py
        ├── addon_two/
        │   ├── __init__.py
        │   ├── operators.py
        │   ├── panels.py
        │   └── utils.py
        ├── dependencies/
        │   └── my_dependency-1.0.0-py3-none-any.whl

Thank you.

1 Like
2

As I was told you need to include each add-on in separate file, you shouldn’t have my_multi_addon folder. That nesting is unnecessary. Install operator just unzips folders in correct directory, if you have multiple add-on folders there it will just drop them.

3

Thank you for the reply. So if I .zip a bundle of add-ons, ‘Install from Disk’ will register all of them together? Would they have one blender_manifest.toml or would each add-on have its own blender_manifest.toml?

4

Each of them will have theres. I think you’re overthinking this. Basically you go to where your add-on folders are, select bunch of them and zip together. IDEALLY this should work and whenever someone installs they’ll get add-ons you selected unzipped in their directory

5

I don’t think it’s as simple as this. From my tests, the zip file needs a blender_manifest.toml or else we get Missing manifest from: /Users/username/Desktop/Test_Bundle.zip

The documentation mentions a “combined add-on.” I am seeking the correct way to set this up.

6

So, if someone creates an extension that offers a feature tweak to Rigify, then their extension archive should also include a copy of the Rigify extension?

If I have a newer version of rigify already installed than they included, what happens when I install this other extension?

2 Likes
7

What you have sounds about right.

The other recommendations I have is to:

  • Leave wheels in a wheels folder (optional).
  • Make sure the add-ons are not registered before you registed them, to avoid duplicated classes.

The latter is important if your add-on may have been installed indepently. The same applies to the independent add-ons as well (since you have no control over the order of their registration).

8

Rigify is a different case since it relies on being on the global namespace. It is more an eco-system for add-ons than an add-on itself. The correct approach for these case is to have a wheel exposing its API ot the global namespace. You can read more details about this here. The same approach will have to be done by BlenderBIM by the way.

9

Thank you for the reply. Could your team please provide an example of a combined add-on or point me to one?

As mentioned before, from my tests, the zip file needs a blender_manifest.toml or else we get a Missing manifest error.

The documentation mentions a “combined add-on.” How do we set up its manifest so that all of the add-ons get registered (while checking for duplicated before registering)?

I have downloaded many of the extensions and haven’t found any that include wheels or other add-ons.

Thank you!

10

Thank you for starting this topic Kevin!
I also didn’t fully understand how this would work in the context of extensions.

I don’t think the dependency (secondary) add-ons will have their own entry under the Add-on preferences.

I think this is the root of the confusion around this part of the documentation.

If you have extension add-on A that relies on add-on B you will just get one entry in the Add-on preferences (for the add-on A bundle).

  • It will register the classes of add-on B
  • It will NOT add an entry for add-on B in the Add-on preferences

dfelinto Can you please confirm that this understanding is correct or not correct?

1 Like
11

I have a basic example of a add-on depending on another add-on

There is some code that checks that the classes are not registered already.

1 Like
12

I found a potential issue that some people might run into. (if I understand everything correctly)

I don’t want to derail this topic, so I started a new one here