blender/scripts/modules/addon_utils.py

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1165 lines
43 KiB
Python
Raw Normal View History

# SPDX-FileCopyrightText: 2011-2023 Blender Authors
#
# SPDX-License-Identifier: GPL-2.0-or-later
__all__ = (
2011-02-25 16:06:14 +00:00
"paths",
"modules",
"check",
"check_extension",
2011-02-25 16:06:14 +00:00
"enable",
"disable",
2017-03-23 18:20:26 +00:00
"disable_all",
2011-02-25 16:06:14 +00:00
"reset_all",
"module_bl_info",
2016-07-29 11:22:27 +00:00
)
import bpy as _bpy
_preferences = _bpy.context.preferences
error_encoding = False
# (name, file, path)
error_duplicates = []
2011-09-23 13:47:29 +00:00
addons_fake_modules = {}
# called only once at startup, avoids calling 'reset_all', correct but slower.
def _initialize_once():
for path in paths():
_bpy.utils._sys_path_ensure_append(path)
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
_initialize_extensions_repos_once()
for addon in _preferences.addons:
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
enable(addon.module)
_initialize_ensure_extensions_addon()
def paths():
Extensions: Support online extensions and move add-ons outside Blender The extensions system allows to extend Blender with connectivity to the internet. Right now it means Blender can discover and install add-ons and themes directly from the internet, and notify users about their updates. By default this is disabled (opt-in), and users can enable it the first time they try to install an extension or visit the Prefences > Extensions tab. If this is enabled, Blender will automatically check for updates for extensions.blender.org upon startup. When will Blender access the remote repositories: * Every time you open the Preferences → Extensions: ALL the enabled repositories get checked for the latest info (json) * Every time you try to install by dragging: ALL the enabled repositories get checked for the latest info (json). * Every time you start Blender: selected repositories get checked for the latest info (json). ------------------ From the Blender code point of view, this means that most of the add-ons and themes originally bundled with Blender will now be available from the online platform, instead of bundled with Blender. The exception are add-ons which are deemed core functionality which just happened to be written as Python add-ons. Links: * Original Extenesions Platform Announcement: https://code.blender.org/2022/10/blender-extensions-platform/ * Extensions website: https://extensions.blender.org/ * User Manual: https://docs.blender.org/manual/en/4.2/extensions/index.html#extensions-index * Technical specifications: https://developer.blender.org/docs/features/extensions/ * Changes on add-ons bundling: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593 ------------------ This PR does the following: * Move extensions out of experimental. * No longer install `scripts/addons` & `scripts/addons_contrib`. * Add `scripts/addons_core` to blender's repository. These add-ons will still be bundled with Blender and will be always enabled in the future, with their preferences moved to be more closely integrated with the rest of Blender. This will happen during the remaining bcon2 period. For more details, see #121830 From scripts/addons: * copy_global_transform.py * hydra_storm * io_anim_bvh * io_curve_svg * io_mesh_uv_layout * io_scene_fbx * io_scene_gltf2 * pose_library * ui_translate * viewport_vr_preview Extra: bl_pkg (scripts/addons_contrib) Note: The STL (legacy) add-on is going to be moved to the extensions platform. There is already a C++ version on core which is enabled by default. All the other add-ons are already available at extensions.blender.org. To use them you need to: * Go to User Preferences > Extensions * You will be greated with an "Online Extensions" message, click on "Enable Repository". * Search the add-on you are looking for (e.g, Import Images as Planes). * Click on Install Over time their maintaince will be transferred over to the community so their development can carry on. If you used to help maintain a bundled add-on please read: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593 Ref: !121825
2024-05-15 12:21:00 +00:00
import os
paths = []
for i, p in enumerate(_bpy.utils.script_paths()):
# Bundled add-ons are always first.
# Since this isn't officially part of the API, print an error so this never silently fails.
addon_dir = os.path.join(p, "addons_core" if i == 0 else "addons")
Extensions: Support online extensions and move add-ons outside Blender The extensions system allows to extend Blender with connectivity to the internet. Right now it means Blender can discover and install add-ons and themes directly from the internet, and notify users about their updates. By default this is disabled (opt-in), and users can enable it the first time they try to install an extension or visit the Prefences > Extensions tab. If this is enabled, Blender will automatically check for updates for extensions.blender.org upon startup. When will Blender access the remote repositories: * Every time you open the Preferences → Extensions: ALL the enabled repositories get checked for the latest info (json) * Every time you try to install by dragging: ALL the enabled repositories get checked for the latest info (json). * Every time you start Blender: selected repositories get checked for the latest info (json). ------------------ From the Blender code point of view, this means that most of the add-ons and themes originally bundled with Blender will now be available from the online platform, instead of bundled with Blender. The exception are add-ons which are deemed core functionality which just happened to be written as Python add-ons. Links: * Original Extenesions Platform Announcement: https://code.blender.org/2022/10/blender-extensions-platform/ * Extensions website: https://extensions.blender.org/ * User Manual: https://docs.blender.org/manual/en/4.2/extensions/index.html#extensions-index * Technical specifications: https://developer.blender.org/docs/features/extensions/ * Changes on add-ons bundling: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593 ------------------ This PR does the following: * Move extensions out of experimental. * No longer install `scripts/addons` & `scripts/addons_contrib`. * Add `scripts/addons_core` to blender's repository. These add-ons will still be bundled with Blender and will be always enabled in the future, with their preferences moved to be more closely integrated with the rest of Blender. This will happen during the remaining bcon2 period. For more details, see #121830 From scripts/addons: * copy_global_transform.py * hydra_storm * io_anim_bvh * io_curve_svg * io_mesh_uv_layout * io_scene_fbx * io_scene_gltf2 * pose_library * ui_translate * viewport_vr_preview Extra: bl_pkg (scripts/addons_contrib) Note: The STL (legacy) add-on is going to be moved to the extensions platform. There is already a C++ version on core which is enabled by default. All the other add-ons are already available at extensions.blender.org. To use them you need to: * Go to User Preferences > Extensions * You will be greated with an "Online Extensions" message, click on "Enable Repository". * Search the add-on you are looking for (e.g, Import Images as Planes). * Click on Install Over time their maintaince will be transferred over to the community so their development can carry on. If you used to help maintain a bundled add-on please read: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593 Ref: !121825
2024-05-15 12:21:00 +00:00
if os.path.isdir(addon_dir):
paths.append(addon_dir)
elif i == 0:
print("Internal error:", addon_dir, "was not found!")
Extensions: Support online extensions and move add-ons outside Blender The extensions system allows to extend Blender with connectivity to the internet. Right now it means Blender can discover and install add-ons and themes directly from the internet, and notify users about their updates. By default this is disabled (opt-in), and users can enable it the first time they try to install an extension or visit the Prefences > Extensions tab. If this is enabled, Blender will automatically check for updates for extensions.blender.org upon startup. When will Blender access the remote repositories: * Every time you open the Preferences → Extensions: ALL the enabled repositories get checked for the latest info (json) * Every time you try to install by dragging: ALL the enabled repositories get checked for the latest info (json). * Every time you start Blender: selected repositories get checked for the latest info (json). ------------------ From the Blender code point of view, this means that most of the add-ons and themes originally bundled with Blender will now be available from the online platform, instead of bundled with Blender. The exception are add-ons which are deemed core functionality which just happened to be written as Python add-ons. Links: * Original Extenesions Platform Announcement: https://code.blender.org/2022/10/blender-extensions-platform/ * Extensions website: https://extensions.blender.org/ * User Manual: https://docs.blender.org/manual/en/4.2/extensions/index.html#extensions-index * Technical specifications: https://developer.blender.org/docs/features/extensions/ * Changes on add-ons bundling: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593 ------------------ This PR does the following: * Move extensions out of experimental. * No longer install `scripts/addons` & `scripts/addons_contrib`. * Add `scripts/addons_core` to blender's repository. These add-ons will still be bundled with Blender and will be always enabled in the future, with their preferences moved to be more closely integrated with the rest of Blender. This will happen during the remaining bcon2 period. For more details, see #121830 From scripts/addons: * copy_global_transform.py * hydra_storm * io_anim_bvh * io_curve_svg * io_mesh_uv_layout * io_scene_fbx * io_scene_gltf2 * pose_library * ui_translate * viewport_vr_preview Extra: bl_pkg (scripts/addons_contrib) Note: The STL (legacy) add-on is going to be moved to the extensions platform. There is already a C++ version on core which is enabled by default. All the other add-ons are already available at extensions.blender.org. To use them you need to: * Go to User Preferences > Extensions * You will be greated with an "Online Extensions" message, click on "Enable Repository". * Search the add-on you are looking for (e.g, Import Images as Planes). * Click on Install Over time their maintaince will be transferred over to the community so their development can carry on. If you used to help maintain a bundled add-on please read: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593 Ref: !121825
2024-05-15 12:21:00 +00:00
return paths
# A version of `paths` that includes extension repositories returning a list `(path, package)` pairs.
#
# Notes on the ``package`` value.
#
# - For top-level modules (the "addons" directories, the value is an empty string)
# because those add-ons can be imported directly.
# - For extension repositories the value is a module string (which can be imported for example)
# where any modules within the `path` can be imported as a sub-module.
# So for example, given a list value of: `("/tmp/repo", "bl_ext.temp_repo")`.
#
# An add-on located at `/tmp/repo/my_handy_addon.py` will have a unique module path of:
# `bl_ext.temp_repo.my_handy_addon`, which can be imported and will be the value of it's `Addon.module`.
def _paths_with_extension_repos():
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
import os
addon_paths = [(path, "") for path in paths()]
Extensions: Support online extensions and move add-ons outside Blender The extensions system allows to extend Blender with connectivity to the internet. Right now it means Blender can discover and install add-ons and themes directly from the internet, and notify users about their updates. By default this is disabled (opt-in), and users can enable it the first time they try to install an extension or visit the Prefences > Extensions tab. If this is enabled, Blender will automatically check for updates for extensions.blender.org upon startup. When will Blender access the remote repositories: * Every time you open the Preferences → Extensions: ALL the enabled repositories get checked for the latest info (json) * Every time you try to install by dragging: ALL the enabled repositories get checked for the latest info (json). * Every time you start Blender: selected repositories get checked for the latest info (json). ------------------ From the Blender code point of view, this means that most of the add-ons and themes originally bundled with Blender will now be available from the online platform, instead of bundled with Blender. The exception are add-ons which are deemed core functionality which just happened to be written as Python add-ons. Links: * Original Extenesions Platform Announcement: https://code.blender.org/2022/10/blender-extensions-platform/ * Extensions website: https://extensions.blender.org/ * User Manual: https://docs.blender.org/manual/en/4.2/extensions/index.html#extensions-index * Technical specifications: https://developer.blender.org/docs/features/extensions/ * Changes on add-ons bundling: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593 ------------------ This PR does the following: * Move extensions out of experimental. * No longer install `scripts/addons` & `scripts/addons_contrib`. * Add `scripts/addons_core` to blender's repository. These add-ons will still be bundled with Blender and will be always enabled in the future, with their preferences moved to be more closely integrated with the rest of Blender. This will happen during the remaining bcon2 period. For more details, see #121830 From scripts/addons: * copy_global_transform.py * hydra_storm * io_anim_bvh * io_curve_svg * io_mesh_uv_layout * io_scene_fbx * io_scene_gltf2 * pose_library * ui_translate * viewport_vr_preview Extra: bl_pkg (scripts/addons_contrib) Note: The STL (legacy) add-on is going to be moved to the extensions platform. There is already a C++ version on core which is enabled by default. All the other add-ons are already available at extensions.blender.org. To use them you need to: * Go to User Preferences > Extensions * You will be greated with an "Online Extensions" message, click on "Enable Repository". * Search the add-on you are looking for (e.g, Import Images as Planes). * Click on Install Over time their maintaince will be transferred over to the community so their development can carry on. If you used to help maintain a bundled add-on please read: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593 Ref: !121825
2024-05-15 12:21:00 +00:00
for repo in _preferences.extensions.repos:
if not repo.enabled:
continue
dirpath = repo.directory
if not os.path.isdir(dirpath):
continue
addon_paths.append((dirpath, "{:s}.{:s}".format(_ext_base_pkg_idname, repo.module)))
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
return addon_paths
def _fake_module(mod_name, mod_path, speedy=True):
global error_encoding
2011-02-25 16:06:14 +00:00
import os
if _bpy.app.debug_python:
print("fake_module", mod_path, mod_name)
if mod_name.startswith(_ext_base_pkg_idname_with_dot):
return _fake_module_from_extension(mod_name, mod_path)
import ast
ModuleType = type(ast)
try:
file_mod = open(mod_path, "r", encoding='UTF-8')
except OSError as ex:
print("Error opening file:", mod_path, ex)
return None
with file_mod:
if speedy:
lines = []
line_iter = iter(file_mod)
l = ""
while not l.startswith("bl_info"):
try:
l = line_iter.readline()
except UnicodeDecodeError as ex:
if not error_encoding:
error_encoding = True
print("Error reading file as UTF-8:", mod_path, ex)
return None
if len(l) == 0:
break
while l.rstrip():
lines.append(l)
try:
l = line_iter.readline()
except UnicodeDecodeError as ex:
if not error_encoding:
error_encoding = True
print("Error reading file as UTF-8:", mod_path, ex)
return None
data = "".join(lines)
else:
data = file_mod.read()
del file_mod
try:
ast_data = ast.parse(data, filename=mod_path)
except BaseException:
print("Syntax error 'ast.parse' can't read:", repr(mod_path))
import traceback
traceback.print_exc()
ast_data = None
body_info = None
if ast_data:
for body in ast_data.body:
if body.__class__ == ast.Assign:
if len(body.targets) == 1:
if getattr(body.targets[0], "id", "") == "bl_info":
body_info = body
break
2011-02-25 16:06:14 +00:00
if body_info:
2011-02-25 16:06:14 +00:00
try:
mod = ModuleType(mod_name)
mod.bl_info = ast.literal_eval(body.value)
mod.__file__ = mod_path
mod.__time__ = os.path.getmtime(mod_path)
2011-02-25 16:06:14 +00:00
except:
print("AST error parsing bl_info for:", repr(mod_path))
2011-02-25 16:06:14 +00:00
import traceback
traceback.print_exc()
return None
return mod
else:
print("Warning: add-on missing 'bl_info', this can cause poor performance!:", repr(mod_path))
return None
def modules_refresh(*, module_cache=addons_fake_modules):
global error_encoding
import os
error_encoding = False
error_duplicates.clear()
2011-02-25 16:06:14 +00:00
modules_stale = set(module_cache.keys())
for path, pkg_id in _paths_with_extension_repos():
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
for mod_name, mod_path in _bpy.path.module_names(path, package=pkg_id):
modules_stale.discard(mod_name)
2011-02-25 16:06:14 +00:00
mod = module_cache.get(mod_name)
if mod is not None:
if mod.__file__ != mod_path:
2018-07-14 07:30:59 +00:00
print(
"multiple addons with the same name:\n"
" {!r}\n"
" {!r}".format(mod.__file__, mod_path)
2018-07-14 07:30:59 +00:00
)
error_duplicates.append((mod.bl_info["name"], mod.__file__, mod_path))
elif (
(mod.__time__ != os.path.getmtime(metadata_path := mod_path)) if not pkg_id else
# Check the manifest time as this is the source of the cache.
(mod.__time_manifest__ != os.path.getmtime(metadata_path := mod.__file_manifest__))
):
print("reloading addon meta-data:", mod_name, repr(metadata_path), "(time-stamp change detected)")
2011-02-25 16:06:14 +00:00
del module_cache[mod_name]
mod = None
if mod is None:
mod = _fake_module(
mod_name,
mod_path,
)
2011-02-25 16:06:14 +00:00
if mod:
module_cache[mod_name] = mod
2011-10-17 06:58:07 +00:00
# just in case we get stale modules, not likely
2011-02-25 16:06:14 +00:00
for mod_stale in modules_stale:
del module_cache[mod_stale]
del modules_stale
PyAPI: use keyword only arguments Use keyword only arguments for the following functions. - addon_utils.module_bl_info 2nd arg `info_basis`. - addon_utils.modules 1st `module_cache`, 2nd arg `refresh`. - addon_utils.modules_refresh 1st arg `module_cache`. - bl_app_template_utils.activate 1nd arg `template_id`. - bl_app_template_utils.import_from_id 2nd arg `ignore_not_found`. - bl_app_template_utils.import_from_path 2nd arg `ignore_not_found`. - bl_keymap_utils.keymap_from_toolbar.generate 2nd & 3rd args `use_fallback_keys` & `use_reset`. - bl_keymap_utils.platform_helpers.keyconfig_data_oskey_from_ctrl 2nd arg `filter_fn`. - bl_ui_utils.bug_report_url.url_prefill_from_blender 1st arg `addon_info`. - bmesh.types.BMFace.copy 1st & 2nd args `verts`, `edges`. - bmesh.types.BMesh.calc_volume 1st arg `signed`. - bmesh.types.BMesh.from_mesh 2nd..4th args `face_normals`, `use_shape_key`, `shape_key_index`. - bmesh.types.BMesh.from_object 3rd & 4th args `cage`, `face_normals`. - bmesh.types.BMesh.transform 2nd arg `filter`. - bmesh.types.BMesh.update_edit_mesh 2nd & 3rd args `loop_triangles`, `destructive`. - bmesh.types.{BMVertSeq,BMEdgeSeq,BMFaceSeq}.sort 1st & 2nd arg `key`, `reverse`. - bmesh.utils.face_split 4th..6th args `coords`, `use_exist`, `example`. - bpy.data.libraries.load 2nd..4th args `link`, `relative`, `assets_only`. - bpy.data.user_map 1st..3rd args `subset`, `key_types, `value_types`. - bpy.msgbus.subscribe_rna 5th arg `options`. - bpy.path.abspath 2nd & 3rd args `start` & `library`. - bpy.path.clean_name 2nd arg `replace`. - bpy.path.ensure_ext 3rd arg `case_sensitive`. - bpy.path.module_names 2nd arg `recursive`. - bpy.path.relpath 2nd arg `start`. - bpy.types.EditBone.transform 2nd & 3rd arg `scale`, `roll`. - bpy.types.Operator.as_keywords 1st arg `ignore`. - bpy.types.Struct.{keyframe_insert,keyframe_delete} 2nd..5th args `index`, `frame`, `group`, `options`. - bpy.types.WindowManager.popup_menu 2nd & 3rd arg `title`, `icon`. - bpy.types.WindowManager.popup_menu_pie 3rd & 4th arg `title`, `icon`. - bpy.utils.app_template_paths 1st arg `subdir`. - bpy.utils.app_template_paths 1st arg `subdir`. - bpy.utils.blend_paths 1st..3rd args `absolute`, `packed`, `local`. - bpy.utils.execfile 2nd arg `mod`. - bpy.utils.keyconfig_set 2nd arg `report`. - bpy.utils.load_scripts 1st & 2nd `reload_scripts` & `refresh_scripts`. - bpy.utils.preset_find 3rd & 4th args `display_name`, `ext`. - bpy.utils.resource_path 2nd & 3rd arg `major`, `minor`. - bpy.utils.script_paths 1st..4th args `subdir`, `user_pref`, `check_all`, `use_user`. - bpy.utils.smpte_from_frame 2nd & 3rd args `fps`, `fps_base`. - bpy.utils.smpte_from_seconds 2nd & 3rd args `fps`, `fps_base`. - bpy.utils.system_resource 2nd arg `subdir`. - bpy.utils.time_from_frame 2nd & 3rd args `fps`, `fps_base`. - bpy.utils.time_to_frame 2nd & 3rd args `fps`, `fps_base`. - bpy.utils.units.to_string 4th..6th `precision`, `split_unit`, `compatible_unit`. - bpy.utils.units.to_value 4th arg `str_ref_unit`. - bpy.utils.user_resource 2nd & 3rd args `subdir`, `create` - bpy_extras.view3d_utils.location_3d_to_region_2d 4th arg `default`. - bpy_extras.view3d_utils.region_2d_to_origin_3d 4th arg `clamp`. - gpu.offscreen.unbind 1st arg `restore`. - gpu_extras.batch.batch_for_shader 4th arg `indices`. - gpu_extras.batch.presets.draw_circle_2d 4th arg `segments`. - gpu_extras.presets.draw_circle_2d 4th arg `segments`. - imbuf.types.ImBuf.resize 2nd arg `resize`. - imbuf.write 2nd arg `filepath`. - mathutils.kdtree.KDTree.find 2nd arg `filter`. - nodeitems_utils.NodeCategory 3rd & 4th arg `descriptions`, `items`. - nodeitems_utils.NodeItem 2nd..4th args `label`, `settings`, `poll`. - nodeitems_utils.NodeItemCustom 1st & 2nd arg `poll`, `draw`. - rna_prop_ui.draw 5th arg `use_edit`. - rna_prop_ui.rna_idprop_ui_get 2nd arg `create`. - rna_prop_ui.rna_idprop_ui_prop_clear 3rd arg `remove`. - rna_prop_ui.rna_idprop_ui_prop_get 3rd arg `create`. - rna_xml.xml2rna 2nd arg `root_rna`. - rna_xml.xml_file_write 4th arg `skip_typemap`.
2021-06-08 08:03:14 +00:00
def modules(*, module_cache=addons_fake_modules, refresh=True):
if refresh or ((module_cache is addons_fake_modules) and modules._is_first):
PyAPI: use keyword only arguments Use keyword only arguments for the following functions. - addon_utils.module_bl_info 2nd arg `info_basis`. - addon_utils.modules 1st `module_cache`, 2nd arg `refresh`. - addon_utils.modules_refresh 1st arg `module_cache`. - bl_app_template_utils.activate 1nd arg `template_id`. - bl_app_template_utils.import_from_id 2nd arg `ignore_not_found`. - bl_app_template_utils.import_from_path 2nd arg `ignore_not_found`. - bl_keymap_utils.keymap_from_toolbar.generate 2nd & 3rd args `use_fallback_keys` & `use_reset`. - bl_keymap_utils.platform_helpers.keyconfig_data_oskey_from_ctrl 2nd arg `filter_fn`. - bl_ui_utils.bug_report_url.url_prefill_from_blender 1st arg `addon_info`. - bmesh.types.BMFace.copy 1st & 2nd args `verts`, `edges`. - bmesh.types.BMesh.calc_volume 1st arg `signed`. - bmesh.types.BMesh.from_mesh 2nd..4th args `face_normals`, `use_shape_key`, `shape_key_index`. - bmesh.types.BMesh.from_object 3rd & 4th args `cage`, `face_normals`. - bmesh.types.BMesh.transform 2nd arg `filter`. - bmesh.types.BMesh.update_edit_mesh 2nd & 3rd args `loop_triangles`, `destructive`. - bmesh.types.{BMVertSeq,BMEdgeSeq,BMFaceSeq}.sort 1st & 2nd arg `key`, `reverse`. - bmesh.utils.face_split 4th..6th args `coords`, `use_exist`, `example`. - bpy.data.libraries.load 2nd..4th args `link`, `relative`, `assets_only`. - bpy.data.user_map 1st..3rd args `subset`, `key_types, `value_types`. - bpy.msgbus.subscribe_rna 5th arg `options`. - bpy.path.abspath 2nd & 3rd args `start` & `library`. - bpy.path.clean_name 2nd arg `replace`. - bpy.path.ensure_ext 3rd arg `case_sensitive`. - bpy.path.module_names 2nd arg `recursive`. - bpy.path.relpath 2nd arg `start`. - bpy.types.EditBone.transform 2nd & 3rd arg `scale`, `roll`. - bpy.types.Operator.as_keywords 1st arg `ignore`. - bpy.types.Struct.{keyframe_insert,keyframe_delete} 2nd..5th args `index`, `frame`, `group`, `options`. - bpy.types.WindowManager.popup_menu 2nd & 3rd arg `title`, `icon`. - bpy.types.WindowManager.popup_menu_pie 3rd & 4th arg `title`, `icon`. - bpy.utils.app_template_paths 1st arg `subdir`. - bpy.utils.app_template_paths 1st arg `subdir`. - bpy.utils.blend_paths 1st..3rd args `absolute`, `packed`, `local`. - bpy.utils.execfile 2nd arg `mod`. - bpy.utils.keyconfig_set 2nd arg `report`. - bpy.utils.load_scripts 1st & 2nd `reload_scripts` & `refresh_scripts`. - bpy.utils.preset_find 3rd & 4th args `display_name`, `ext`. - bpy.utils.resource_path 2nd & 3rd arg `major`, `minor`. - bpy.utils.script_paths 1st..4th args `subdir`, `user_pref`, `check_all`, `use_user`. - bpy.utils.smpte_from_frame 2nd & 3rd args `fps`, `fps_base`. - bpy.utils.smpte_from_seconds 2nd & 3rd args `fps`, `fps_base`. - bpy.utils.system_resource 2nd arg `subdir`. - bpy.utils.time_from_frame 2nd & 3rd args `fps`, `fps_base`. - bpy.utils.time_to_frame 2nd & 3rd args `fps`, `fps_base`. - bpy.utils.units.to_string 4th..6th `precision`, `split_unit`, `compatible_unit`. - bpy.utils.units.to_value 4th arg `str_ref_unit`. - bpy.utils.user_resource 2nd & 3rd args `subdir`, `create` - bpy_extras.view3d_utils.location_3d_to_region_2d 4th arg `default`. - bpy_extras.view3d_utils.region_2d_to_origin_3d 4th arg `clamp`. - gpu.offscreen.unbind 1st arg `restore`. - gpu_extras.batch.batch_for_shader 4th arg `indices`. - gpu_extras.batch.presets.draw_circle_2d 4th arg `segments`. - gpu_extras.presets.draw_circle_2d 4th arg `segments`. - imbuf.types.ImBuf.resize 2nd arg `resize`. - imbuf.write 2nd arg `filepath`. - mathutils.kdtree.KDTree.find 2nd arg `filter`. - nodeitems_utils.NodeCategory 3rd & 4th arg `descriptions`, `items`. - nodeitems_utils.NodeItem 2nd..4th args `label`, `settings`, `poll`. - nodeitems_utils.NodeItemCustom 1st & 2nd arg `poll`, `draw`. - rna_prop_ui.draw 5th arg `use_edit`. - rna_prop_ui.rna_idprop_ui_get 2nd arg `create`. - rna_prop_ui.rna_idprop_ui_prop_clear 3rd arg `remove`. - rna_prop_ui.rna_idprop_ui_prop_get 3rd arg `create`. - rna_xml.xml2rna 2nd arg `root_rna`. - rna_xml.xml_file_write 4th arg `skip_typemap`.
2021-06-08 08:03:14 +00:00
modules_refresh(module_cache=module_cache)
modules._is_first = False
2011-02-25 16:06:14 +00:00
mod_list = list(module_cache.values())
mod_list.sort(
key=lambda mod: (
mod.bl_info.get("category", ""),
mod.bl_info.get("name", ""),
)
)
2011-02-25 16:06:14 +00:00
return mod_list
2018-07-03 04:27:53 +00:00
modules._is_first = True
def check(module_name):
"""
Returns the loaded state of the addon.
:arg module_name: The name of the addon and module.
:type module_name: string
:return: (loaded_default, loaded_state)
:rtype: tuple of booleans
"""
import sys
loaded_default = module_name in _preferences.addons
mod = sys.modules.get(module_name)
loaded_state = (
(mod is not None) and
getattr(mod, "__addon_enabled__", Ellipsis)
)
if loaded_state is Ellipsis:
2018-07-14 07:30:59 +00:00
print(
"Warning: addon-module", module_name, "found module "
2018-07-14 07:30:59 +00:00
"but without '__addon_enabled__' field, "
"possible name collision from file:",
repr(getattr(mod, "__file__", "<unknown>")),
)
loaded_state = False
if mod and getattr(mod, "__addon_persistent__", False):
loaded_default = True
return loaded_default, loaded_state
def check_extension(module_name):
"""
Return true if the module is an extension.
"""
return module_name.startswith(_ext_base_pkg_idname_with_dot)
# utility functions
def _addon_ensure(module_name):
addons = _preferences.addons
addon = addons.get(module_name)
if not addon:
addon = addons.new()
addon.module = module_name
def _addon_remove(module_name):
addons = _preferences.addons
while module_name in addons:
addon = addons.get(module_name)
if addon:
addons.remove(addon)
def enable(module_name, *, default_set=False, persistent=False, handle_error=None):
"""
Enables an addon by name.
:arg module_name: the name of the addon and module.
:type module_name: string
:arg default_set: Set the user-preference.
:type default_set: bool
:arg persistent: Ensure the addon is enabled for the entire session (after loading new files).
:type persistent: bool
:arg handle_error: Called in the case of an error, taking an exception argument.
:type handle_error: function
2011-10-17 06:58:07 +00:00
:return: the loaded module or None on failure.
:rtype: module
"""
import os
import sys
import importlib
from bpy_restrict_state import RestrictBlend
is_extension = module_name.startswith(_ext_base_pkg_idname_with_dot)
if handle_error is None:
def handle_error(ex):
if isinstance(ex, ImportError):
# NOTE: checking "Add-on " prefix is rather weak,
# it's just a way to avoid the noise of a full trace-back when
# an add-on is simply missing on the file-system.
if (type(msg := ex.msg) is str) and msg.startswith("Add-on "):
print(msg)
return
import traceback
traceback.print_exc()
# reload if the mtime changes
mod = sys.modules.get(module_name)
# chances of the file _not_ existing are low, but it could be removed
# Set to `mod.__file__` or None.
mod_file = None
if (
(mod is not None) and
(mod_file := mod.__file__) is not None and
os.path.exists(mod_file)
):
if getattr(mod, "__addon_enabled__", False):
# This is an unlikely situation,
# re-register if the module is enabled.
# Note: the UI doesn't allow this to happen,
# in most cases the caller should 'check()' first.
try:
mod.unregister()
except BaseException as ex:
print("Exception in module unregister():", (mod_file or module_name))
handle_error(ex)
return None
mod.__addon_enabled__ = False
mtime_orig = getattr(mod, "__time__", 0)
mtime_new = os.path.getmtime(mod_file)
if mtime_orig != mtime_new:
print("module changed on disk:", repr(mod_file), "reloading...")
try:
importlib.reload(mod)
except BaseException as ex:
handle_error(ex)
del sys.modules[module_name]
return None
mod.__addon_enabled__ = False
# add the addon first it may want to initialize its own preferences.
# must remove on fail through.
if default_set:
_addon_ensure(module_name)
# Split registering up into 3 steps so we can undo
# if it fails par way through.
# Disable the context: using the context at all
# while loading an addon is really bad, don't do it!
with RestrictBlend():
# 1) try import
try:
# Use instead of `__import__` so that sub-modules can eventually be supported.
# This is also documented to be the preferred way to import modules.
mod = importlib.import_module(module_name)
if (mod_file := mod.__file__) is None:
# This can happen when:
# - The add-on has been removed but there are residual `.pyc` files left behind.
# - An extension is a directory that doesn't contain an `__init__.py` file.
#
# Include a message otherwise the "cause:" for failing to load the module is left blank.
# Include the `__path__` when available so there is a reference to the location that failed to load.
raise ImportError(
"module loaded with no associated file, __path__={!r}, aborting!".format(
getattr(mod, "__path__", None)
),
name=module_name,
)
mod.__time__ = os.path.getmtime(mod_file)
mod.__addon_enabled__ = False
except BaseException as ex:
# If the add-on doesn't exist, don't print full trace-back because the back-trace is in this case
# is verbose without any useful details. A missing path is better communicated in a short message.
# Account for `ImportError` & `ModuleNotFoundError`.
if isinstance(ex, ImportError):
if ex.name == module_name:
ex.msg = "Add-on not loaded: \"{:s}\", cause: {:s}".format(module_name, str(ex))
# Issue with an add-on from an extension repository, report a useful message.
elif is_extension and module_name.startswith(ex.name + "."):
repo_id = module_name[len(_ext_base_pkg_idname_with_dot):].rpartition(".")[0]
repo = next(
(repo for repo in _preferences.extensions.repos if repo.module == repo_id),
None,
)
if repo is None:
ex.msg = (
"Add-on not loaded: \"{:s}\", cause: extension repository \"{:s}\" doesn't exist".format(
module_name, repo_id,
)
)
elif not repo.enabled:
ex.msg = (
"Add-on not loaded: \"{:s}\", cause: extension repository \"{:s}\" is disabled".format(
module_name, repo_id,
)
)
else:
# The repository exists and is enabled, it should have imported.
ex.msg = "Add-on not loaded: \"{:s}\", cause: {:s}".format(module_name, str(ex))
handle_error(ex)
if default_set:
_addon_remove(module_name)
return None
if is_extension:
# Handle the case the an extension has `bl_info` (which is not used for extensions).
# Note that internally a `bl_info` is added based on the extensions manifest - for compatibility.
# So it's important not to use this one.
bl_info = getattr(mod, "bl_info", None)
if bl_info is not None:
# Use `_init` to detect when `bl_info` was generated from the manifest, see: `_bl_info_from_extension`.
if type(bl_info) is dict and "_init" not in bl_info:
# This print is noisy, hide behind a debug flag.
# Once `bl_info` is fully deprecated this should be changed to always print a warning.
if _bpy.app.debug_python:
print(
"Add-on \"{:s}\" has a \"bl_info\" which will be ignored in favor of \"{:s}\"".format(
module_name, _ext_manifest_filename_toml,
)
)
# Always remove as this is not expected to exist and will be lazily initialized.
del mod.bl_info
# 2) Try register collected modules.
# Removed register_module, addons need to handle their own registration now.
from _bpy import _bl_owner_id_get, _bl_owner_id_set
owner_id_prev = _bl_owner_id_get()
_bl_owner_id_set(module_name)
# 3) Try run the modules register function.
try:
mod.register()
except BaseException as ex:
print("Exception in module register():", (mod_file or module_name))
handle_error(ex)
del sys.modules[module_name]
if default_set:
_addon_remove(module_name)
return None
finally:
_bl_owner_id_set(owner_id_prev)
# * OK loaded successfully! *
mod.__addon_enabled__ = True
mod.__addon_persistent__ = persistent
if _bpy.app.debug_python:
print("\taddon_utils.enable", mod.__name__)
return mod
def disable(module_name, *, default_set=False, handle_error=None):
"""
Disables an addon by name.
:arg module_name: The name of the addon and module.
:type module_name: string
:arg default_set: Set the user-preference.
:type default_set: bool
:arg handle_error: Called in the case of an error, taking an exception argument.
:type handle_error: function
"""
import sys
if handle_error is None:
def handle_error(_ex):
import traceback
traceback.print_exc()
mod = sys.modules.get(module_name)
2023-09-05 00:49:20 +00:00
# Possible this add-on is from a previous session and didn't load a
# module this time. So even if the module is not found, still disable
2023-09-05 00:49:20 +00:00
# the add-on in the user preferences.
if mod and getattr(mod, "__addon_enabled__", False) is not False:
mod.__addon_enabled__ = False
mod.__addon_persistent__ = False
try:
mod.unregister()
except BaseException as ex:
2018-07-14 07:30:59 +00:00
mod_path = getattr(mod, "__file__", module_name)
print("Exception in module unregister():", repr(mod_path))
del mod_path
handle_error(ex)
else:
2018-07-14 07:30:59 +00:00
print(
"addon_utils.disable: {:s} not {:s}".format(
module_name,
"loaded" if mod is None else "enabled",
)
2018-07-14 07:30:59 +00:00
)
# could be in more than once, unlikely but better do this just in case.
if default_set:
_addon_remove(module_name)
if _bpy.app.debug_python:
print("\taddon_utils.disable", module_name)
def reset_all(*, reload_scripts=False):
"""
Sets the addon state based on the user preferences.
"""
import sys
# Ensures stale `addons_fake_modules` isn't used.
modules._is_first = True
addons_fake_modules.clear()
for path, pkg_id in _paths_with_extension_repos():
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
if not pkg_id:
_bpy.utils._sys_path_ensure_append(path)
for mod_name, _mod_path in _bpy.path.module_names(path, package=pkg_id):
is_enabled, is_loaded = check(mod_name)
# first check if reload is needed before changing state.
if reload_scripts:
import importlib
mod = sys.modules.get(mod_name)
if mod:
importlib.reload(mod)
if is_enabled == is_loaded:
pass
elif is_enabled:
enable(mod_name)
elif is_loaded:
print("\taddon_utils.reset_all unloading", mod_name)
disable(mod_name)
2017-03-23 18:20:26 +00:00
def disable_all():
import sys
2018-10-19 06:49:16 +00:00
# Collect modules to disable first because dict can be modified as we disable.
# NOTE: don't use `getattr(item[1], "__addon_enabled__", False)` because this runs on all modules,
# including 3rd party modules unrelated to Blender.
#
# Some modules may have their own `__getattr__` and either:
# - Not raise an `AttributeError` (is they should),
# causing `hasattr` & `getattr` to raise an exception instead of treating the attribute as missing.
# - Generate modules dynamically, modifying `sys.modules` which is being iterated over,
# causing a RuntimeError: "dictionary changed size during iteration".
#
# Either way, running 3rd party logic here can cause undefined behavior.
# Use direct `__dict__` access to bypass `__getattr__`, see: #111649.
modules = sys.modules.copy()
2018-10-19 06:49:16 +00:00
addon_modules = [
item for item in modules.items()
if type(mod_dict := getattr(item[1], "__dict__", None)) is dict
if mod_dict.get("__addon_enabled__")
2018-10-19 06:49:16 +00:00
]
# Check the enabled state again since it's possible the disable call
# of one add-on disables others.
2018-10-19 06:49:16 +00:00
for mod_name, mod in addon_modules:
2017-03-23 18:20:26 +00:00
if getattr(mod, "__addon_enabled__", False):
disable(mod_name)
def _blender_manual_url_prefix():
return "https://docs.blender.org/manual/{:s}/{:d}.{:d}".format(
_bpy.utils.manual_language_code(),
*_bpy.app.version[:2],
)
def _bl_info_basis():
return {
"name": "",
"author": "",
"version": (),
"blender": (),
"location": "",
"description": "",
"doc_url": "",
"support": 'COMMUNITY',
"category": "",
"warning": "",
"show_expanded": False,
}
PyAPI: use keyword only arguments Use keyword only arguments for the following functions. - addon_utils.module_bl_info 2nd arg `info_basis`. - addon_utils.modules 1st `module_cache`, 2nd arg `refresh`. - addon_utils.modules_refresh 1st arg `module_cache`. - bl_app_template_utils.activate 1nd arg `template_id`. - bl_app_template_utils.import_from_id 2nd arg `ignore_not_found`. - bl_app_template_utils.import_from_path 2nd arg `ignore_not_found`. - bl_keymap_utils.keymap_from_toolbar.generate 2nd & 3rd args `use_fallback_keys` & `use_reset`. - bl_keymap_utils.platform_helpers.keyconfig_data_oskey_from_ctrl 2nd arg `filter_fn`. - bl_ui_utils.bug_report_url.url_prefill_from_blender 1st arg `addon_info`. - bmesh.types.BMFace.copy 1st & 2nd args `verts`, `edges`. - bmesh.types.BMesh.calc_volume 1st arg `signed`. - bmesh.types.BMesh.from_mesh 2nd..4th args `face_normals`, `use_shape_key`, `shape_key_index`. - bmesh.types.BMesh.from_object 3rd & 4th args `cage`, `face_normals`. - bmesh.types.BMesh.transform 2nd arg `filter`. - bmesh.types.BMesh.update_edit_mesh 2nd & 3rd args `loop_triangles`, `destructive`. - bmesh.types.{BMVertSeq,BMEdgeSeq,BMFaceSeq}.sort 1st & 2nd arg `key`, `reverse`. - bmesh.utils.face_split 4th..6th args `coords`, `use_exist`, `example`. - bpy.data.libraries.load 2nd..4th args `link`, `relative`, `assets_only`. - bpy.data.user_map 1st..3rd args `subset`, `key_types, `value_types`. - bpy.msgbus.subscribe_rna 5th arg `options`. - bpy.path.abspath 2nd & 3rd args `start` & `library`. - bpy.path.clean_name 2nd arg `replace`. - bpy.path.ensure_ext 3rd arg `case_sensitive`. - bpy.path.module_names 2nd arg `recursive`. - bpy.path.relpath 2nd arg `start`. - bpy.types.EditBone.transform 2nd & 3rd arg `scale`, `roll`. - bpy.types.Operator.as_keywords 1st arg `ignore`. - bpy.types.Struct.{keyframe_insert,keyframe_delete} 2nd..5th args `index`, `frame`, `group`, `options`. - bpy.types.WindowManager.popup_menu 2nd & 3rd arg `title`, `icon`. - bpy.types.WindowManager.popup_menu_pie 3rd & 4th arg `title`, `icon`. - bpy.utils.app_template_paths 1st arg `subdir`. - bpy.utils.app_template_paths 1st arg `subdir`. - bpy.utils.blend_paths 1st..3rd args `absolute`, `packed`, `local`. - bpy.utils.execfile 2nd arg `mod`. - bpy.utils.keyconfig_set 2nd arg `report`. - bpy.utils.load_scripts 1st & 2nd `reload_scripts` & `refresh_scripts`. - bpy.utils.preset_find 3rd & 4th args `display_name`, `ext`. - bpy.utils.resource_path 2nd & 3rd arg `major`, `minor`. - bpy.utils.script_paths 1st..4th args `subdir`, `user_pref`, `check_all`, `use_user`. - bpy.utils.smpte_from_frame 2nd & 3rd args `fps`, `fps_base`. - bpy.utils.smpte_from_seconds 2nd & 3rd args `fps`, `fps_base`. - bpy.utils.system_resource 2nd arg `subdir`. - bpy.utils.time_from_frame 2nd & 3rd args `fps`, `fps_base`. - bpy.utils.time_to_frame 2nd & 3rd args `fps`, `fps_base`. - bpy.utils.units.to_string 4th..6th `precision`, `split_unit`, `compatible_unit`. - bpy.utils.units.to_value 4th arg `str_ref_unit`. - bpy.utils.user_resource 2nd & 3rd args `subdir`, `create` - bpy_extras.view3d_utils.location_3d_to_region_2d 4th arg `default`. - bpy_extras.view3d_utils.region_2d_to_origin_3d 4th arg `clamp`. - gpu.offscreen.unbind 1st arg `restore`. - gpu_extras.batch.batch_for_shader 4th arg `indices`. - gpu_extras.batch.presets.draw_circle_2d 4th arg `segments`. - gpu_extras.presets.draw_circle_2d 4th arg `segments`. - imbuf.types.ImBuf.resize 2nd arg `resize`. - imbuf.write 2nd arg `filepath`. - mathutils.kdtree.KDTree.find 2nd arg `filter`. - nodeitems_utils.NodeCategory 3rd & 4th arg `descriptions`, `items`. - nodeitems_utils.NodeItem 2nd..4th args `label`, `settings`, `poll`. - nodeitems_utils.NodeItemCustom 1st & 2nd arg `poll`, `draw`. - rna_prop_ui.draw 5th arg `use_edit`. - rna_prop_ui.rna_idprop_ui_get 2nd arg `create`. - rna_prop_ui.rna_idprop_ui_prop_clear 3rd arg `remove`. - rna_prop_ui.rna_idprop_ui_prop_get 3rd arg `create`. - rna_xml.xml2rna 2nd arg `root_rna`. - rna_xml.xml_file_write 4th arg `skip_typemap`.
2021-06-08 08:03:14 +00:00
def module_bl_info(mod, *, info_basis=None):
if info_basis is None:
info_basis = _bl_info_basis()
addon_info = getattr(mod, "bl_info", {})
# avoid re-initializing
if "_init" in addon_info:
return addon_info
if not addon_info:
if mod.__name__.startswith(_ext_base_pkg_idname_with_dot):
addon_info, filepath_toml = _bl_info_from_extension(mod.__name__, mod.__file__)
if addon_info is None:
# Unexpected, this is a malformed extension if meta-data can't be loaded.
print("module_bl_info: failed to extract meta-data from", filepath_toml)
# Continue to initialize dummy data.
addon_info = {}
mod.bl_info = addon_info
for key, value in info_basis.items():
addon_info.setdefault(key, value)
if not addon_info["name"]:
addon_info["name"] = mod.__name__
doc_url = addon_info["doc_url"]
if doc_url:
doc_url_prefix = "{BLENDER_MANUAL_URL}"
if doc_url_prefix in doc_url:
addon_info["doc_url"] = doc_url.replace(
doc_url_prefix,
_blender_manual_url_prefix(),
)
addon_info["_init"] = None
return addon_info
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
# -----------------------------------------------------------------------------
# Extension Utilities
def _version_int_left_digits(x):
# Parse as integer until the first non-digit.
return int(x[:next((i for i, c in enumerate(x) if not c.isdigit()), len(x))] or "0")
def _bl_info_from_extension(mod_name, mod_path):
# Extract the `bl_info` from an extensions manifest.
# This is returned as a module which has a `bl_info` variable.
# When support for non-extension add-ons is dropped (Blender v5.0 perhaps)
# this can be updated not to use a fake module.
import os
import tomllib
bl_info = _bl_info_basis()
filepath_toml = os.path.join(os.path.dirname(mod_path), _ext_manifest_filename_toml)
try:
with open(filepath_toml, "rb") as fh:
data = tomllib.load(fh)
except FileNotFoundError:
print("Warning: add-on missing manifest, this can cause poor performance!:", repr(filepath_toml))
return None, filepath_toml
except BaseException as ex:
print("Error:", str(ex), "in", filepath_toml)
return None, filepath_toml
# This isn't a full validation which happens on package install/update.
if (value := data.get("name", None)) is None:
print("Error: missing \"name\" in", filepath_toml)
return None, filepath_toml
if type(value) is not str:
print("Error: \"name\" is not a string in", filepath_toml)
return None, filepath_toml
bl_info["name"] = value
if (value := data.get("version", None)) is None:
print("Error: missing \"version\" in", filepath_toml)
return None, filepath_toml
if type(value) is not str:
print("Error: \"version\" is not a string in", filepath_toml)
return None, filepath_toml
try:
value = tuple(
(int if i < 2 else _version_int_left_digits)(x)
for i, x in enumerate(value.split(".", 2))
)
except BaseException as ex:
print("Error: \"version\" is not a semantic version (X.Y.Z) in ", filepath_toml)
return None, filepath_toml
bl_info["version"] = value
if (value := data.get("blender_version_min", None)) is None:
print("Error: missing \"blender_version_min\" in", filepath_toml)
return None, filepath_toml
if type(value) is not str:
print("Error: \"blender_version_min\" is not a string in", filepath_toml)
return None, filepath_toml
try:
value = tuple(int(x) for x in value.split("."))
except BaseException as ex:
print("Error:", str(ex), "in \"blender_version_min\"", filepath_toml)
return None, filepath_toml
bl_info["blender"] = value
# Only print warnings since description is not a mandatory field.
if (value := data.get("tagline", None)) is None:
print("Warning: missing \"tagline\" in", filepath_toml)
elif type(value) is not str:
print("Warning: \"tagline\" is not a string", filepath_toml)
else:
bl_info["description"] = value
if (value := data.get("maintainer", None)) is None:
print("Error: missing \"author\" in", filepath_toml)
return None, filepath_toml
if type(value) is not str:
print("Error: \"maintainer\" is not a string", filepath_toml)
return None, filepath_toml
bl_info["author"] = value
bl_info["category"] = "Development" # Dummy, will be removed.
return bl_info, filepath_toml
def _fake_module_from_extension(mod_name, mod_path):
import os
bl_info, filepath_toml = _bl_info_from_extension(mod_name, mod_path)
if bl_info is None:
return None
ModuleType = type(os)
mod = ModuleType(mod_name)
mod.bl_info = bl_info
mod.__file__ = mod_path
mod.__time__ = os.path.getmtime(mod_path)
# NOTE(@ideasman42): Add non-standard manifest variables to the "fake" module,
# this isn't ideal as it moves further away from the return value being minimal fake-module
# (where `__name__` and `__file__` are typically used).
# A custom type could be used, however this needs to be done carefully
# as all users of `addon_utils.modules(..)` need to be updated.
mod.__file_manifest__ = filepath_toml
mod.__time_manifest__ = os.path.getmtime(filepath_toml)
return mod
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
# -----------------------------------------------------------------------------
# Extensions
def _initialize_ensure_extensions_addon():
Extensions: Support online extensions and move add-ons outside Blender The extensions system allows to extend Blender with connectivity to the internet. Right now it means Blender can discover and install add-ons and themes directly from the internet, and notify users about their updates. By default this is disabled (opt-in), and users can enable it the first time they try to install an extension or visit the Prefences > Extensions tab. If this is enabled, Blender will automatically check for updates for extensions.blender.org upon startup. When will Blender access the remote repositories: * Every time you open the Preferences → Extensions: ALL the enabled repositories get checked for the latest info (json) * Every time you try to install by dragging: ALL the enabled repositories get checked for the latest info (json). * Every time you start Blender: selected repositories get checked for the latest info (json). ------------------ From the Blender code point of view, this means that most of the add-ons and themes originally bundled with Blender will now be available from the online platform, instead of bundled with Blender. The exception are add-ons which are deemed core functionality which just happened to be written as Python add-ons. Links: * Original Extenesions Platform Announcement: https://code.blender.org/2022/10/blender-extensions-platform/ * Extensions website: https://extensions.blender.org/ * User Manual: https://docs.blender.org/manual/en/4.2/extensions/index.html#extensions-index * Technical specifications: https://developer.blender.org/docs/features/extensions/ * Changes on add-ons bundling: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593 ------------------ This PR does the following: * Move extensions out of experimental. * No longer install `scripts/addons` & `scripts/addons_contrib`. * Add `scripts/addons_core` to blender's repository. These add-ons will still be bundled with Blender and will be always enabled in the future, with their preferences moved to be more closely integrated with the rest of Blender. This will happen during the remaining bcon2 period. For more details, see #121830 From scripts/addons: * copy_global_transform.py * hydra_storm * io_anim_bvh * io_curve_svg * io_mesh_uv_layout * io_scene_fbx * io_scene_gltf2 * pose_library * ui_translate * viewport_vr_preview Extra: bl_pkg (scripts/addons_contrib) Note: The STL (legacy) add-on is going to be moved to the extensions platform. There is already a C++ version on core which is enabled by default. All the other add-ons are already available at extensions.blender.org. To use them you need to: * Go to User Preferences > Extensions * You will be greated with an "Online Extensions" message, click on "Enable Repository". * Search the add-on you are looking for (e.g, Import Images as Planes). * Click on Install Over time their maintaince will be transferred over to the community so their development can carry on. If you used to help maintain a bundled add-on please read: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593 Ref: !121825
2024-05-15 12:21:00 +00:00
module_name = "bl_pkg"
if module_name not in _preferences.addons:
enable(module_name, default_set=True, persistent=True)
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
# Module-like class, store singletons.
class _ext_global:
__slots__ = ()
# Store a map of `preferences.extensions.repos` -> `module_id`.
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
# Only needed to detect renaming between `bpy.app.handlers.extension_repos_update_{pre & post}` events.
#
# The first dictionary is for enabled repositories, the second for disabled repositories
# which can be ignored in most cases and is only needed for a module rename.
idmap_pair = {}, {}
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
# The base package created by `JunctionModuleHandle`.
module_handle = None
# The name (in `sys.modules`) keep this short because it's stored as part of add-on modules name.
_ext_base_pkg_idname = "bl_ext"
_ext_base_pkg_idname_with_dot = _ext_base_pkg_idname + "."
_ext_manifest_filename_toml = "blender_manifest.toml"
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
def _extension_preferences_idmap():
repos_idmap = {}
repos_idmap_disabled = {}
Extensions: Support online extensions and move add-ons outside Blender The extensions system allows to extend Blender with connectivity to the internet. Right now it means Blender can discover and install add-ons and themes directly from the internet, and notify users about their updates. By default this is disabled (opt-in), and users can enable it the first time they try to install an extension or visit the Prefences > Extensions tab. If this is enabled, Blender will automatically check for updates for extensions.blender.org upon startup. When will Blender access the remote repositories: * Every time you open the Preferences → Extensions: ALL the enabled repositories get checked for the latest info (json) * Every time you try to install by dragging: ALL the enabled repositories get checked for the latest info (json). * Every time you start Blender: selected repositories get checked for the latest info (json). ------------------ From the Blender code point of view, this means that most of the add-ons and themes originally bundled with Blender will now be available from the online platform, instead of bundled with Blender. The exception are add-ons which are deemed core functionality which just happened to be written as Python add-ons. Links: * Original Extenesions Platform Announcement: https://code.blender.org/2022/10/blender-extensions-platform/ * Extensions website: https://extensions.blender.org/ * User Manual: https://docs.blender.org/manual/en/4.2/extensions/index.html#extensions-index * Technical specifications: https://developer.blender.org/docs/features/extensions/ * Changes on add-ons bundling: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593 ------------------ This PR does the following: * Move extensions out of experimental. * No longer install `scripts/addons` & `scripts/addons_contrib`. * Add `scripts/addons_core` to blender's repository. These add-ons will still be bundled with Blender and will be always enabled in the future, with their preferences moved to be more closely integrated with the rest of Blender. This will happen during the remaining bcon2 period. For more details, see #121830 From scripts/addons: * copy_global_transform.py * hydra_storm * io_anim_bvh * io_curve_svg * io_mesh_uv_layout * io_scene_fbx * io_scene_gltf2 * pose_library * ui_translate * viewport_vr_preview Extra: bl_pkg (scripts/addons_contrib) Note: The STL (legacy) add-on is going to be moved to the extensions platform. There is already a C++ version on core which is enabled by default. All the other add-ons are already available at extensions.blender.org. To use them you need to: * Go to User Preferences > Extensions * You will be greated with an "Online Extensions" message, click on "Enable Repository". * Search the add-on you are looking for (e.g, Import Images as Planes). * Click on Install Over time their maintaince will be transferred over to the community so their development can carry on. If you used to help maintain a bundled add-on please read: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593 Ref: !121825
2024-05-15 12:21:00 +00:00
for repo in _preferences.extensions.repos:
if repo.enabled:
repos_idmap[repo.as_pointer()] = repo.module
else:
repos_idmap_disabled[repo.as_pointer()] = repo.module
return repos_idmap, repos_idmap_disabled
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
def _extension_dirpath_from_preferences():
repos_dict = {}
Extensions: Support online extensions and move add-ons outside Blender The extensions system allows to extend Blender with connectivity to the internet. Right now it means Blender can discover and install add-ons and themes directly from the internet, and notify users about their updates. By default this is disabled (opt-in), and users can enable it the first time they try to install an extension or visit the Prefences > Extensions tab. If this is enabled, Blender will automatically check for updates for extensions.blender.org upon startup. When will Blender access the remote repositories: * Every time you open the Preferences → Extensions: ALL the enabled repositories get checked for the latest info (json) * Every time you try to install by dragging: ALL the enabled repositories get checked for the latest info (json). * Every time you start Blender: selected repositories get checked for the latest info (json). ------------------ From the Blender code point of view, this means that most of the add-ons and themes originally bundled with Blender will now be available from the online platform, instead of bundled with Blender. The exception are add-ons which are deemed core functionality which just happened to be written as Python add-ons. Links: * Original Extenesions Platform Announcement: https://code.blender.org/2022/10/blender-extensions-platform/ * Extensions website: https://extensions.blender.org/ * User Manual: https://docs.blender.org/manual/en/4.2/extensions/index.html#extensions-index * Technical specifications: https://developer.blender.org/docs/features/extensions/ * Changes on add-ons bundling: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593 ------------------ This PR does the following: * Move extensions out of experimental. * No longer install `scripts/addons` & `scripts/addons_contrib`. * Add `scripts/addons_core` to blender's repository. These add-ons will still be bundled with Blender and will be always enabled in the future, with their preferences moved to be more closely integrated with the rest of Blender. This will happen during the remaining bcon2 period. For more details, see #121830 From scripts/addons: * copy_global_transform.py * hydra_storm * io_anim_bvh * io_curve_svg * io_mesh_uv_layout * io_scene_fbx * io_scene_gltf2 * pose_library * ui_translate * viewport_vr_preview Extra: bl_pkg (scripts/addons_contrib) Note: The STL (legacy) add-on is going to be moved to the extensions platform. There is already a C++ version on core which is enabled by default. All the other add-ons are already available at extensions.blender.org. To use them you need to: * Go to User Preferences > Extensions * You will be greated with an "Online Extensions" message, click on "Enable Repository". * Search the add-on you are looking for (e.g, Import Images as Planes). * Click on Install Over time their maintaince will be transferred over to the community so their development can carry on. If you used to help maintain a bundled add-on please read: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593 Ref: !121825
2024-05-15 12:21:00 +00:00
for repo in _preferences.extensions.repos:
if not repo.enabled:
continue
repos_dict[repo.module] = repo.directory
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
return repos_dict
def _extension_dirpath_from_handle():
repos_info = {}
for module_id, module in _ext_global.module_handle.submodule_items():
# Account for it being unset although this should never happen unless script authors
# meddle with the modules.
try:
dirpath = module.__path__[0]
except BaseException:
dirpath = ""
repos_info[module_id] = dirpath
return repos_info
# Ensure the add-ons follow changes to repositories, enabling, disabling and module renaming.
def _initialize_extension_repos_post_addons_prepare(
module_handle,
*,
submodules_del,
submodules_add,
submodules_rename_module,
submodules_del_disabled,
submodules_rename_module_disabled,
):
addons_to_enable = []
if not (
submodules_del or
submodules_add or
submodules_rename_module or
submodules_del_disabled or
submodules_rename_module_disabled
):
return addons_to_enable
# All preferences info.
# Map: `repo_id -> {submodule_id -> addon, ...}`.
addon_userdef_info = {}
for addon in _preferences.addons:
module = addon.module
if not module.startswith(_ext_base_pkg_idname_with_dot):
continue
module_id, submodule_id = module[len(_ext_base_pkg_idname_with_dot):].partition(".")[0::2]
try:
addon_userdef_info[module_id][submodule_id] = addon
except KeyError:
addon_userdef_info[module_id] = {submodule_id: addon}
# All run-time info.
# Map: `module_id -> {submodule_id -> module, ...}`.
addon_runtime_info = {}
for module_id, repo_module in module_handle.submodule_items():
extensions_info = {}
for submodule_id in dir(repo_module):
if submodule_id.startswith("_"):
continue
mod = getattr(repo_module, submodule_id)
# Filter out non add-on, non-modules.
if not hasattr(mod, "__addon_enabled__"):
continue
extensions_info[submodule_id] = mod
addon_runtime_info[module_id] = extensions_info
del extensions_info
# Apply changes to add-ons.
if submodules_add:
# Re-enable add-ons that exist in the user preferences,
# this lets the add-ons state be restored when toggling a repository.
for module_id, _dirpath in submodules_add:
repo_userdef = addon_userdef_info.get(module_id, {})
repo_runtime = addon_runtime_info.get(module_id, {})
for submodule_id, addon in repo_userdef.items():
module_name_next = "{:s}.{:s}.{:s}".format(_ext_base_pkg_idname, module_id, submodule_id)
# Only default & persistent add-ons are kept for re-activation.
default_set = True
persistent = True
addons_to_enable.append((module_name_next, addon, default_set, persistent))
for module_id_prev, module_id_next in submodules_rename_module:
repo_userdef = addon_userdef_info.get(module_id_prev, {})
repo_runtime = addon_runtime_info.get(module_id_prev, {})
for submodule_id, mod in repo_runtime.items():
if not getattr(mod, "__addon_enabled__", False):
continue
module_name_prev = "{:s}.{:s}.{:s}".format(_ext_base_pkg_idname, module_id_prev, submodule_id)
module_name_next = "{:s}.{:s}.{:s}".format(_ext_base_pkg_idname, module_id_next, submodule_id)
disable(module_name_prev, default_set=False)
addon = repo_userdef.get(submodule_id)
default_set = addon is not None
persistent = getattr(mod, "__addon_persistent__", False)
addons_to_enable.append((module_name_next, addon, default_set, persistent))
for module_id_prev, module_id_next in submodules_rename_module_disabled:
repo_userdef = addon_userdef_info.get(module_id_prev, {})
repo_runtime = addon_runtime_info.get(module_id_prev, {})
for submodule_id, addon in repo_userdef.items():
mod = repo_runtime.get(submodule_id)
if mod is not None and getattr(mod, "__addon_enabled__", False):
continue
# Either there is no run-time data or the module wasn't enabled.
# Rename the add-on without enabling it so the next time it's enabled it's preferences are kept.
module_name_next = "{:s}.{:s}.{:s}".format(_ext_base_pkg_idname, module_id_next, submodule_id)
addon.module = module_name_next
if submodules_del:
repo_module_map = {repo.module: repo for repo in _preferences.extensions.repos}
for module_id in submodules_del:
repo_userdef = addon_userdef_info.get(module_id, {})
repo_runtime = addon_runtime_info.get(module_id, {})
repo = repo_module_map.get(module_id)
default_set = True
if repo and not repo.enabled:
# The repository exists but has been disabled, keep the add-on preferences
# because the user may want to re-enable the repository temporarily.
default_set = False
for submodule_id, mod in repo_runtime.items():
module_name_prev = "{:s}.{:s}.{:s}".format(_ext_base_pkg_idname, module_id, submodule_id)
disable(module_name_prev, default_set=default_set)
del repo
del repo_module_map
if submodules_del_disabled:
for module_id_prev in submodules_del_disabled:
repo_userdef = addon_userdef_info.get(module_id_prev, {})
for submodule_id in repo_userdef.keys():
module_name_prev = "{:s}.{:s}.{:s}".format(_ext_base_pkg_idname, module_id_prev, submodule_id)
disable(module_name_prev, default_set=True)
return addons_to_enable
# Enable add-ons after the modules have been manipulated.
def _initialize_extension_repos_post_addons_restore(addons_to_enable):
if not addons_to_enable:
return
for (module_name_next, addon, default_set, persistent) in addons_to_enable:
# Ensure the preferences are kept.
if addon is not None:
addon.module = module_name_next
enable(module_name_next, default_set=default_set, persistent=persistent)
# Needed for module rename.
modules._is_first = True
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
# Use `bpy.app.handlers.extension_repos_update_{pre/post}` to track changes to extension repositories
# and sync the changes to the Python module.
@_bpy.app.handlers.persistent
def _initialize_extension_repos_pre(*_):
_ext_global.idmap_pair = _extension_preferences_idmap()
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
@_bpy.app.handlers.persistent
def _initialize_extension_repos_post(*_, is_first=False):
# When enabling extensions for the first time, ensure the add-on is enabled.
_initialize_ensure_extensions_addon()
do_addons = not is_first
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
# Map `module_id` -> `dirpath`.
repos_info_prev = _extension_dirpath_from_handle()
repos_info_next = _extension_dirpath_from_preferences()
# Map `repo.as_pointer()` -> `module_id`.
repos_idmap_prev, repos_idmap_prev_disabled = _ext_global.idmap_pair
repos_idmap_next, repos_idmap_next_disabled = _extension_preferences_idmap()
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
# Map `module_id` -> `repo.as_pointer()`.
repos_idmap_next_reverse = {value: key for key, value in repos_idmap_next.items()}
Extensions: Support online extensions and move add-ons outside Blender The extensions system allows to extend Blender with connectivity to the internet. Right now it means Blender can discover and install add-ons and themes directly from the internet, and notify users about their updates. By default this is disabled (opt-in), and users can enable it the first time they try to install an extension or visit the Prefences > Extensions tab. If this is enabled, Blender will automatically check for updates for extensions.blender.org upon startup. When will Blender access the remote repositories: * Every time you open the Preferences → Extensions: ALL the enabled repositories get checked for the latest info (json) * Every time you try to install by dragging: ALL the enabled repositories get checked for the latest info (json). * Every time you start Blender: selected repositories get checked for the latest info (json). ------------------ From the Blender code point of view, this means that most of the add-ons and themes originally bundled with Blender will now be available from the online platform, instead of bundled with Blender. The exception are add-ons which are deemed core functionality which just happened to be written as Python add-ons. Links: * Original Extenesions Platform Announcement: https://code.blender.org/2022/10/blender-extensions-platform/ * Extensions website: https://extensions.blender.org/ * User Manual: https://docs.blender.org/manual/en/4.2/extensions/index.html#extensions-index * Technical specifications: https://developer.blender.org/docs/features/extensions/ * Changes on add-ons bundling: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593 ------------------ This PR does the following: * Move extensions out of experimental. * No longer install `scripts/addons` & `scripts/addons_contrib`. * Add `scripts/addons_core` to blender's repository. These add-ons will still be bundled with Blender and will be always enabled in the future, with their preferences moved to be more closely integrated with the rest of Blender. This will happen during the remaining bcon2 period. For more details, see #121830 From scripts/addons: * copy_global_transform.py * hydra_storm * io_anim_bvh * io_curve_svg * io_mesh_uv_layout * io_scene_fbx * io_scene_gltf2 * pose_library * ui_translate * viewport_vr_preview Extra: bl_pkg (scripts/addons_contrib) Note: The STL (legacy) add-on is going to be moved to the extensions platform. There is already a C++ version on core which is enabled by default. All the other add-ons are already available at extensions.blender.org. To use them you need to: * Go to User Preferences > Extensions * You will be greated with an "Online Extensions" message, click on "Enable Repository". * Search the add-on you are looking for (e.g, Import Images as Planes). * Click on Install Over time their maintaince will be transferred over to the community so their development can carry on. If you used to help maintain a bundled add-on please read: https://devtalk.blender.org/t/changes-to-add-on-bundling-4-2-onwards/34593 Ref: !121825
2024-05-15 12:21:00 +00:00
# Mainly needed when the state of repositories changes at run-time:
# factory settings then load preferences for example.
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
#
# Filter `repos_idmap_prev` so only items which were also in the `repos_info_prev` are included.
# This is an awkward situation, they should be in sync, however when enabling the experimental option
# means the preferences wont have changed, but the module will not be in sync with the preferences.
# Support this by removing items in `repos_idmap_prev` which aren't also initialized in the managed package.
#
# The only situation this would be useful to keep is if we want to support renaming a package
# that manipulates all add-ons using it, when those add-ons are in the preferences but have not had
# their package loaded. It's possible we want to do this but is also reasonably obscure.
for repo_id_prev, module_id_prev in list(repos_idmap_prev.items()):
if module_id_prev not in repos_info_prev:
del repos_idmap_prev[repo_id_prev]
submodules_add = [] # List of module names to add: `(module_id, dirpath)`.
submodules_del = [] # List of module names to remove: `module_id`.
submodules_rename_module = [] # List of module names: `(module_id_src, module_id_dst)`.
submodules_rename_dirpath = [] # List of module names: `(module_id, dirpath)`.
renamed_prev = set()
renamed_next = set()
# Detect rename modules & module directories.
for module_id_next, dirpath_next in repos_info_next.items():
# Lookup never fails, as the "next" values use: `preferences.extensions.repos`.
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
repo_id = repos_idmap_next_reverse[module_id_next]
# Lookup may fail if this is a newly added module.
# Don't attempt to setup `submodules_add` though as it's possible
# the module name persists while the underlying `repo_id` changes.
module_id_prev = repos_idmap_prev.get(repo_id)
if module_id_prev is None:
continue
# Detect rename.
if module_id_next != module_id_prev:
submodules_rename_module.append((module_id_prev, module_id_next))
renamed_prev.add(module_id_prev)
renamed_next.add(module_id_next)
# Detect `dirpath` change.
if dirpath_next != repos_info_prev[module_id_prev]:
submodules_rename_dirpath.append((module_id_next, dirpath_next))
# Detect added modules.
for module_id, dirpath in repos_info_next.items():
if (module_id not in repos_info_prev) and (module_id not in renamed_next):
submodules_add.append((module_id, dirpath))
# Detect deleted modules.
for module_id, _dirpath in repos_info_prev.items():
if (module_id not in repos_info_next) and (module_id not in renamed_prev):
submodules_del.append(module_id)
if do_addons:
submodules_del_disabled = [] # A version of `submodules_del` for disabled repositories.
submodules_rename_module_disabled = [] # A version of `submodules_rename_module` for disabled repositories.
# Detect deleted modules.
for repo_id_prev, module_id_prev in repos_idmap_prev_disabled.items():
if (
(repo_id_prev not in repos_idmap_next_disabled) and
(repo_id_prev not in repos_idmap_next)
):
submodules_del_disabled.append(module_id_prev)
# Detect rename of disabled modules.
for repo_id_next, module_id_next in repos_idmap_next_disabled.items():
module_id_prev = repos_idmap_prev_disabled.get(repo_id_next)
if module_id_prev is None:
continue
# Detect rename.
if module_id_next != module_id_prev:
submodules_rename_module_disabled.append((module_id_prev, module_id_next))
addons_to_enable = _initialize_extension_repos_post_addons_prepare(
_ext_global.module_handle,
submodules_del=submodules_del,
submodules_add=submodules_add,
submodules_rename_module=submodules_rename_module,
submodules_del_disabled=submodules_del_disabled,
submodules_rename_module_disabled=submodules_rename_module_disabled,
)
del submodules_del_disabled, submodules_rename_module_disabled
# Apply changes to the `_ext_base_pkg_idname` named module so it matches extension data from the preferences.
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
module_handle = _ext_global.module_handle
for module_id in submodules_del:
module_handle.unregister_submodule(module_id)
for module_id, dirpath in submodules_add:
module_handle.register_submodule(module_id, dirpath)
for module_id_prev, module_id_next in submodules_rename_module:
module_handle.rename_submodule(module_id_prev, module_id_next)
for module_id, dirpath in submodules_rename_dirpath:
module_handle.rename_directory(module_id, dirpath)
_ext_global.idmap_pair[0].clear()
_ext_global.idmap_pair[1].clear()
if do_addons:
_initialize_extension_repos_post_addons_restore(addons_to_enable)
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
# Force refreshing if directory paths change.
if submodules_del or submodules_add or submodules_rename_dirpath:
modules._is_first = True
def _initialize_extensions_site_packages(*, create=False):
# Add extension site-packages to `sys.path` (if it exists).
# Use for wheels.
import os
import sys
# NOTE: follow the structure of `~/.local/lib/python#.##/site-packages`
# because some wheels contain paths pointing to parent directories,
# referencing `../../../bin` for example - to install binaries into `~/.local/bin`,
# so this can't simply be treated as a module directory unless those files would be excluded
# which may interfere with the wheels functionality.
site_packages = os.path.join(
_bpy.utils.user_resource('EXTENSIONS'),
".local",
"lib",
"python{:d}.{:d}".format(sys.version_info.major, sys.version_info.minor),
"site-packages",
)
if create:
if not os.path.exists(site_packages):
os.makedirs(site_packages)
found = True
else:
found = os.path.exists(site_packages)
if found:
# Ensure the wheels `site-packages` are added before all other site-packages.
# This is important for extensions modules get priority over system modules.
# Without this, installing a module into the systems site-packages (`/usr/lib/python#.##/site-packages`)
# could break an extension which already had a different version of this module installed locally.
from site import getsitepackages
index = None
if builtin_site_packages := set(getsitepackages()):
for i, dirpath in enumerate(sys.path):
if dirpath in builtin_site_packages:
index = i
break
if index is None:
sys.path.append(site_packages)
else:
sys.path.insert(index, site_packages)
else:
try:
sys.path.remove(site_packages)
except ValueError:
pass
return site_packages if found else None
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
def _initialize_extensions_repos_once():
from bpy_extras.extensions.junction_module import JunctionModuleHandle
module_handle = JunctionModuleHandle(_ext_base_pkg_idname)
module_handle.register_module()
_ext_global.module_handle = module_handle
# Ensure extensions wheels can be loaded (when found).
_initialize_extensions_site_packages()
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
# Setup repositories for the first time.
# Intentionally don't call `_initialize_extension_repos_pre` as this is the first time,
# the previous state is not useful to read.
_initialize_extension_repos_post(is_first=True)
PyAPI: add-on name-spacing for extension repositories Support name-spaced add-ons, exposed via user configurable extension repositories. Directories for add-ons can be added at run-time and are name-spaced to avoid name-collisions with Python modules or add-ons from other repositories. This is exposed as an experimental feature "Extension Repositories". Details: - A `bUserExtensionRepo` type which represents a repository which is listed in the add-ons repository. - `JunctionModuleHandle` class to manage a package with sub-modules which can point to arbitrary locations. - `bpy.app.handlers._extension_repos_update_{pre/post}` internal callbacks run before/after changes to extension repositories, callbacks are used to sync the changes to the Python package that exposes these to add-ons. - The size of an add-on name has been increased so a user-defined package prefix can be included without enforcing shorter add-on names. - Functionality relating to package management has been left out of this change and will be developed separately. Further work: - While a repository can be renamed, enabled add-ons aren't renamed. Eventually we might want to support this although we could also disallow renaming repositories with add-ons enabled as the name isn't all that significant. - Removing a repository should remove all the add-ons located in this repository. - Sub-module names are currently restricted to `[A-Za-z]+[A-Za-z0-9_]*` we might want to relax this to allow unicode characters (we might still want to disallow `-` or any characters that would prevent attribute access in code). Ref !110869. Reviewed By: brecht
2023-08-09 10:15:34 +00:00
# Internal handlers intended for Blender's own handling of repositories.
_bpy.app.handlers._extension_repos_update_pre.append(_initialize_extension_repos_pre)
_bpy.app.handlers._extension_repos_update_post.append(_initialize_extension_repos_post)