*** Addons Breakages 2.79 master Nightly Builds)***

Coding Released Scripts and Themes
1

hi,
Just a heads up about incoming addons breakages and api changes and new rules!

2.79 release is fairly safe from these changes.

A new change restricts the use of duplicate class names.
Put simple, if you use a duplicated class name your addon will fail activation.
This includes addons preferences and any other class name duplicates.
BF task here: https://developer.blender.org/T52564

“the use of duplicate class names has been restricted, we plan to, after 2.79 release, to address these issues.
please note these issues will not be in 2.79 release but are in nightly builds.
it’s good to be aware of this issue, i’m trying to keep addons repo clean for 2.79 release, then come in and fix all the issues in nightly, whilst not polluting addons master with fixes that might be conflicting with release.”

More information will follow.

2

Hi, I think mesh_looptools.py is one of them

Capture.JPG702×171 33.8 KB

3

yes, looking at the issue, might be worth solving sooner rather than later

4

Finally it was a wild wild west in blender when every addon was all over the place… I hope these new rules makes the interface a bit more tolerable and addons nice and somewhat organized.

5

I can understand why the bl_idname should be unique for every class but why the class name?

I don’t want that my class names have any influence on other addons and vice versa. This would also mean that I would have to prefix all class names (I have a couple of hundred). I did this for the bl_idname already.

Having to insert a prefix for every class name greatly reduces code quality in my opinion (again, this is ok for the bl_idname).

I also fully agree with this statement by Campbell: “we could keep bpy.types for built-in types, not add dynamically registered classes at all.” (https://lists.blender.org/pipermail/bf-committers/2017-August/048653.html)

My hope was that this the reduces dependencies between addons and not to add a new one (like unique class names).

6

fiendish55, i say before i say again, enable every addon in blender and the ui is very good in 2.79.
as far as addons included in blender, we are already running a tight ship with 95% well organized context sensitive addons with good ui placement. I did this. and introduced many rules. Change tab category in addons that have panels, so you can move them where you like is one. thanks to lijenstina for following this through. addons that use tabs must use the same tab as other addons within the same/similar context is another reduced tabs significantly for built in addons.

This thread is to raise awareness for addons devs in blender and external, that their addons may be broken and to identify issues with any other addons in blender that lijenstina and myself will need to fix.
like looptools.

Thanks.

7

Jacques Lucke,
One problem with non unique class names is if 2 addons have the same class name the last activated will deactivate the first in the ui.
This follow through to deactivation, unregistered both classes, sometimes removing ui elements also.
I had not read the mail you linked, not sure…
All I’m doing here is a heads up, i really don’t like the decision as I have 100’s of addons in my repo, many many with duplicate class names. i think this rule could have been left to 2.8 where we plan to be stricter on many levels. It broke far too many addons so close to the end of the 2.79 series. Effectively making buildbot builds useless imo.
edit: *not useless, but there’s the potential for conflicts if you develop in nightly builds between addons

What we need to do is set up a wiki page with new conventions/rules/guidelines so people use better practices from the beginning. (show people how to write better addons.

Keep in mind only buildbot builds are affected, 2.79 release and 2.79rc are not affected by this change.
as the change follows through to 2.8 this means first update addons for this change then… 2.8
Which makes a lot more work for the small addons team.

Thanks

8

Does it mean that we’ll have to name the class with a specific name ?
For example, for an Looptool operator, it would be necessary to name the class something like:
LOOPTOOLS_OT_my_operator_name
?

9

One problem with non unique class names is if 2 addons have the same class name the last activated will deactivate the first in the ui.

Not true. Just tested this in the release candidate. I can easily declare two panels in different files with the same class name. They need to have unique "bl_idname"s though. I don’t get why a class would need to have two names that identify it.

Just to make this clear, I’m not against this change because it means much more work for me, in fact I only had to change a single line in Animation Nodes to make it compatible with the current release candidate. I just think it is wrong.

Here is a little example addon I just created to show that having the same class name twice is not actually a problem at all:
https://drive.google.com/file/d/0B7m1nartBYvrUXoteGR3NnNnbUU/view?usp=sharing

10

hi,
we were discussing this in irc yesterday.
LOOPTOOLS_OT_my_operator_name seems a good solution.
i’m really thinking of external devs here also, such a change will mean external devs that call the old name will need to update.
given the addon is currently broken in master, we need to fix. it’s easy fix.

my current proposal is to leave everything as is in 2.79rc2 and 2.79 release.
as far as looptools and any addons that call looptools/other potential conflicts, it’s all working and no change needed for 2.79 release. safe!

issues as i see are this:
2.79 is ok.
master/nightly builds some addons no longer work.
if we fix master and add new class names to individual classes, this will not harm most external addons unless they call the specific class.
using loop tools as an example, if we fix the “Curve” class, it will be still safe if your addon calls the main ui class, but if your addon reuses the classes individually the “Curve” class will need to be changed in your addon too.

thus the paradox begins…
We will end up with different class names in 2.79 release and 2.79 master, basically forking our own addons.

this is ok as long as external addons devs don’t fix their addons too early.
I would say if your developing addons for Blender 2.79 you Should use 2.79rc2 (blender tagged rc builds) as your test/working build atm, if your using classes from other activated addons. we have kept this working for the 2.79 release branch, but will be changing the class names in several addons in the master branch, so your addons will work with 2.79, but maybe not with 2.79 master.

some solutions i have done in the past to prevent duplicate class names:
I duplicated the internal space_view3d.py, all the menus/classes and reused them here:
dynamic spacebar menu addon:
in blender the class is: VIEW3D_MT_view_align
in the addon it’s: VIEW3D_MT_View_Align
to take this further, i duplicated the spacebar menu and made it a panel:
contrib addon “Dynamic Toolshelf”
by this time i’m deep in dupliclassville, so i added a prefix “2” to all the classes to make them unique.

Jacques Lucke,
not talking about within the same addon, but this should be avoided too i guess.
this example: https://github.com/meta-androcto/blenderpython/tree/master/scripts/addons_extern/AF_view3d_mod
run it as an addon in the addons folder, enable it and disable it and watch the ui vanish.

11

Either way you have to introduce change compared to status quo.

In the case of UI Panels and Menus they’ll need an unique bl_idname for them to register, but that is not required so very often those classes don’t have them.

Having a class name like SomethingRandom and a different bl_idname as the real identifier that will be registered and used internally, makes the situation more confusing to manage. In addition, using the SomethingRandom.bl_idname for calling them in the UI is cryptic.

As for the future using the register_module call will be discouraged too.
If we want to have templates where scripts need to be loaded/reloaded on the fly, the registration phase must be much more clear and comprehensible than before as it exposes the possible registration issues to more users.

Having a pattern that is the same structure for both bl_idname and registered class name is a good policy to have as the add-on maker has to think only about the original name of the add-on and use it as a prefix (the exact way in which is done should be open to debate - do we use the context of the class followed by the add-on name or the add-on name).
That issue touches search too.

Often copy-pastes of code using the same operator, panel or menu can be found.
To check those, all the add-ons have to be enabled which is something that if not tested can go unnoticed for a long time.

The only real issue is the exact convention that should be clear and documented with examples.
As the API changes are introduced for 2.8 most of the add-ons will need some work anyway.

12

How long is this breakage issue going to continue? I cannot use nightly’s because a number of addons no longer play nice.

13

It seems to me that addons that uses the Boolean modifier won’t work with the nightly builds because the option Bmesh of Carve for this modifier is removed? For example Hardops, Boxcutter, Speedsculpt.

14

What about prefixing any class name with a timestamp created by Blender itself when the addon is enabled during installation process, effectively creating a versioning system? Or some similar hashing system?
Then add checking for the bl_idname before you either install or uninstall, so avoiding duplicates installation of the same addon and correct removals…
Afaik Blender addons are loaded dynamically (I anyway have not looked at the code, so I could be missing something…)
I think that would not take a big change in Blender code, while renaming classes is absolutely messy and crazy and unnecessary. Moreover, this will slow down consistency of shipments a lot, because of addons developers late timings… let alone code reading problems…

15

BoolTool and Carver MT are now fixed. (Carver 1.1.8 should be available in the tomorrow build - so 27th Feb one, Bool Tool was fixed before).
The change itself is relatively small from a script side. Just commenting out the Some_boolean_Object_variable.solver = line will make the script work again. For instance in Carver it is the lines:

BoolMod.solver = bpy.context.scene.CarverSolver

For more advanced stuff the versioning can be used:


if bpy.app.version < (2, 79, 2):
    BoolMod.solver = bpy.context.scene.CarverSolver

That will make it work on 2.79a but disabled on master.

16

This should really be done in a way that doesn’t break scripts that are no longer maintained. I don’t know what that way is, but this seems like it’s creating a problem where one didn’t previously exist.

Guidelines are cool, hard rules that make an addon fail to activate when they otherwise would be fine are not.

17

If you have a class with the same name or bl_idname it will fail to register / unregister or silently overwrite an existing one. Suddenly a shortcut doesn’t work, the menu brings up a different operator etc. The user has to redo the startup and / or userpref blend as it probably gets corrupted if saved with a state like that. That’s how Blender behaved for years. In the long run, add-on developers have to deal with supporting those bug reports from users.

Generally, unmainted add-ons can have other subtle issues that will make them fail, as some small changes to the API will produce breakages.

18

Maybe I’m missing something. As far as I get, addon registration is managed by Blender during addons installation, in the usual way, is it?

So… let’s consider about it a bit more.

Developer X addon is named “Addon X”.
Developer Y addon is named “Addon X”.

Nothing prevents a developer from choosing any name he wants during the addon creation. He can do so because naming collision is handled by Blender during the addon installation.

User A installs Developer X addon “Addon X”, then
User A installs Developer Y addon “Addon X”. It has a conflicting name and the installation fails.
Developer Y has to change the addon name.

Right, you say. Let’s see. Now,

User B installs Developer Y addon “Addon X”, then
User B installs Developer X addon “Addon X”. It has a conflicting name and the installation fails.
Developer X has to change the addon name.

And so on to the end of time.

Can you see the recursion in this? THIS IS NOT GOING TO WORK.

19

The developer can call the add-on whatever they want in bl_info. It’s just a label string used for search. However if you try to install the add-on with a file name (if it is a single file like some_addon.py or a folder some_folder_containing_addon_stuff) a warning will show up that you have duplicate add-ons. For instance, in version 2.67b:

blender_2.67b_duplicate_addon_module_name.png982×624 23.2 KB

That how things are for years and it is not anything new. And it is still the same in current master and 2.8, apart from - now the add-on name and file locations of the duplicates will be shown. In this case, Blender leaves to the user to decide which add-on to keep. Concerning the future, it is planned somewhere down the line to have an add-on manager that could possibly handle issues like different versions, updates etc.

20

That would be the best solution, short of a central managed plugin system…