The current check() function doesn't account for workspace filtering, so for addons to reliably be able to integrate with each other, they have to add this extra check. Not anymore!
It might be better to add a 3rd boolean to the return tuple of the check() function instead. If that solution is deemed safe in backwards-compatibility terms then I'm happy to do that instead.
Details
Details
- Reviewers
Campbell Barton (campbellbarton)
Diff Detail
Diff Detail
- Repository
- rB Blender
- Branch
- arcpatch-D13129 (branched from master)
- Build Status
Buildable 21981 Build 21981: arc lint + arc unit
Event Timeline
Comment Actions
This seems fine but marking as request changes because I'd like to consider a few things...
- Have the ability to check an add-on is enabled (without the context).
- Have the ability to check the add-on is enabled and active in the work-space.
Even though check provides this, it's mainly intended for internal use, (in fact this module is mainly for internal use).
Also, an add-on may be enabled without being enabled in the preferences, so I'd like to double check that this will work properly.
Comment Actions
If the addon is disabled in the user preferences, it cannot be enabled on a per workspace basis, because only addons that are enabled in the preferences show up at all in the workspace addon filter list. Maybe I misunderstand what you mean here.
Even though check provides this, it's mainly intended for internal use, (in fact this module is mainly for internal use).
Perhaps I should expose these functions in release/scripts/modules/bpy/utils/__init__.py, so they're available via bpy.utils.is_addon_active/enabled()?
I propose to leave the current is_addon_active() function in the patch as it is: Requires context, and uses that to check for workspace filtering.
But in addition, I can add an is_addon_enabled() function which is basically just
def is_addon_enabled(module_name):
return addon_utils.check(module_name)[1]LMK what you think about those ideas.