When a registered class has a non-registered superclass,
rna_info.BuildRNAInfo entered an eternal loop.
The while loop in `rna_info.get_py_class_from_rna` was not mutating the
variables within the loop nor the variable in its condition, meaning it
would loop infinitely if the loop didn't exit in its first iteration.
When yielding registered classes in `subclasses_recurse`, the function
was erroneously checking if the class' superclass was registered rather
than checking the class itself, causing registered classes to be skipped
if their superclass was not also registered. If the class to be found
was skipped, the while loop would not exit in its first iteration and
would thus loop infinitely.
The while loop has been modified to iterate through each base rna type
until there is no further base type.
The `subclasses_recurse` function now correctly checks whether the
subclass is registered, not its superclass, when determining if the
subclass should be yielded.
Besides the fix, no functional changes are expected, the generated
Python API docs remain unchanged.
Ref: !108256
Previously add-ons were sorted by category & name, remove the category
only sorting by name since the category is no longer displayed and
isn't part of extension meta-data. Now the add-ons are sorted by name
(case insensitive).
Details:
- Store add-ons modules sorted to avoid having to sort on every redraw.
- addon_utils.modules() now returns an iterator.
Changes to an extensions manifest weren't accounted for.
This was particularly a problem for "System" extensions which aren't
intended to be managed inside Blender however the problem existed for
any changes made outside of Blender.
Now enabled extensions are checked on startup to ensure:
- They are compatible with Blender.
- The Python wheels are synchronized.
Resolves#123645.
Details:
- Any extension incompatibilities prevent the add-on being enabled
with a message printing the reason for it being disabled.
- Incompatible add-ons are kept enabled in the preferences to avoid
loosing their own preferences and allow for an upgrade to restore
compatibility.
- To avoid slowing down Blender's startup:
- Checks are skipped when no extensions are enabled
(as is the case for `--factory-startup` & running tests).
- Compatibility data is cached so in common case,
the cache is loaded and all enabled extensions `stat` their
manifests to detect changes without having to parse them.
- The cache is re-generated if any extensions change or the
Blender/Python version changes.
- Compatibility data is updated:
- On startup (when needed).
- On an explicit "Refresh Local"
(mainly for developers who may edit the manifest).
- When refreshing extensions after install/uninstall etc.
since an incompatible extensions may become compatible
after an update.
- When reloading preferences.
- Additional info is shown when the `--debug-python` is enabled,
if there are ever issues with the extension compatibility cache
generation not working as expected.
- The behavior for Python wheels has changed so they are only setup
when the extension is enabled. This was done to simplify startup
checks and has the benefit that an installed but disabled extension
never runs code - as the ability to install wheels means it could
have been imported from other scripts. It also means users can disable
an extension to avoid wheel version conflicts.
This does add the complication however that enabling add-on which is
an extension must first ensure it's wheels are setup.
See `addon_utils.extensions_refresh(..)`.
See code-comments for further details.
The BLT_I18N_MSGID_MULTI_CTXT() macro allows extracting a single
message into up to 16 different contexts. The regex to do that was
slightly wrong because it did not account for the macro potentially
ending with a ",".
The contexts for "New" were also sorted.
Pull Request: https://projects.blender.org/blender/blender/pulls/123793
Prevent potential problems from untrusted XML (typically themes)
traversing into data outside the intended targets.
From what I can tell it's not currently possible but changes to RNA
could allow for this which would likely go by unnoticed.
Further details in code-comments.
Provide a convenient way to access a writable directory for extensions.
This will typically be accessed via:
bpy.utils.extension_path_user(__package__, create=True)
This API is provided as some extensions on extensions.blender.org
are writing into the extensions own directory which is error prone:
- The extensions own directory is removed when upgrading.
- Users may not have write access to the extensions directory,
especially with "System" repositories which may be on shared network
drives for example.
These directories are only removed when:
- Uninstalling the extension.
- Removing the repository and its files.
The new extension system introduces tags, similar to categories from
legacy add-ons, and permissions. A hardcoded list is supported for
each, available in the docs:
- https://docs.blender.org/manual/en/dev/advanced/extensions/tags.html
- https://developer.blender.org/docs/features/extensions/schema/
This change allows extraction of these new metadata to the translation
files.
In order to disambiguate the new messages, tags use the new "Script"
translation context. Permissions are lower case, so there is a low
risk of collision, and they use the default context.
While the tags are defined per-platform, with extensions.blender.org
being the only one available currently, they are extracted as a single
list.
Pull Request: https://projects.blender.org/blender/blender/pulls/123150
The issue was that when applying the keyingsets
`Whole Character` and `LocRotScale & Custom Properties` the
enum property of a rigify rig was not keyed.
The reason it was not keyed was just because
it was not specified in the compatible types in the keying set.
The fix is to just add `bpy.types.EnumProperty` to the list.
Pull Request: https://projects.blender.org/blender/blender/pulls/122377
* Drop the repository - let's combine tags in a single list (per type)
to avoid duplications in the future.
* Give a more sensitive name for tthe property, to avoid tags.tags.
This patch removes the Auto Render option from the compositor. This is
done for the following reason:
- The option didn't really work except in the case of transforming an
object. So it wasn't really reliable.
- It made little sense to use since the introduction of the Viewport
Compositor.
- It had a number of UX issues, including the fact that it can't be used
with animation playback, and the fact that rendering can get in the
way of the UI depending on the preferences for temporary editors.
Pull Request: https://projects.blender.org/blender/blender/pulls/123132
- The "location" and "warning" fields in bl_info are no longer exposed
in the interface, so there is no need to extract them any more.
- Some add-ons do not define a description (Copy Global Transform for
example), so they should be skipped.
- Some third-party legacy add-ons do not use the 'support' field, and
that can cause an error in extraction. Since this won't happen
for built-in add-ons, checking that an add-on is built-in is enough.
Pull Request: https://projects.blender.org/blender/blender/pulls/122970
All add-ons were being scanned at startup, while this didn't cause
errors it was noticeable with extensions where any errors in the
manifest were being reported at startup, even when running with
factory-startup (including blender's own tests).
Address two issues:
- The logic to "reset" add-ons, so as to match the preferences when
reverting or resetting preferences always ran on startup.
This occurred because a check for Python being initialized was
incorrectly used to detect that this wasn't the first time preferences
were being loaded (regression in [0]).
- Resetting add-ons scanned all add-ons (including disabled add-ons) to
ensure their module cache is up to date. Since this the cache is
lazily initialized, it's simpler to set it as uninitialized as
resetting the add-ons doesn't require the cached meta-data.
[0]: 497bc4d19977abc7b9e2c0f5024a23057e680954
autopep8_format_paths.py was never wired up in the windows tooling,
this PR wires it up, to get around a 8191 limitation for command
lines on windows an alternative "--no-subprocess" option has been
introduced to call the pep8 module directly from python.
TODO: A subprocess is still used for getting the version information
Contributors:
- @campbellbarton fixes to autopep8_format_paths.py to support
the -no-subprocess option.
Pull Request: https://projects.blender.org/blender/blender/pulls/120794
Originally this would replace scripts that come bundled with Blender,
but it's unclear how this is useful.
Searching for this online mainly leads to people asking how they can
use it to add scripts. For example in a studio environment you might
want to deploy add-ons and startup scripts for all users.
Even if you wanted to use it for replacement though, it wasn't really
doing that and inconsistent for different types of scripts:
* startup: ignored
* modules: replaces bundled scripts
* presets: adds to bundled scripts
* addons (in 4.1): ignored
* addons_core (in 4.2): ignored
* startup/bl_app_templates_system: replaces bundled scripts
This change makes it add scripts from this path for all. This is a
breaking change, though arguably this feature was just broken to
begin with and not used much in practice because of that.
The alternative would be add a new set of environment variables to
avoid breaking existing behavior. But that also means keeping around the
broken behavior or fixing it in another way.
Supporting multiple paths may be used too, but for now just support
a single one as doing this for all BLENDER_SYSTEM variables is
non-trivial. The main use case for that would be add-ons anyway, and
those will mainly be handled through upcoming
BLENDER_SYSTEM_EXTENSIONS instead.
Ref #122512
Pull Request: https://projects.blender.org/blender/blender/pulls/122689
The translation extraction goes through each keyconfig preset file and
activates it in order to extract its messages. This change makes it
restore the original config, otherwise it would end up switching to
Industry Compatible.
Pull Request: https://projects.blender.org/blender/blender/pulls/122789
