addon_utils.enable/disable now handle wheels so that the functions can
be used with extension add-ons.
A new argument `refresh_handled` supports scripts handing refresh
themselves which is needed to avoid refreshing many times in cases
when there are multiple calls to enable/disable.
This is mostly useful for internal operations.
Support multiple extensions with different Python versions in a similar
way to how "platforms" are handled now.
This will be needed when Blender upgrades to a newer version of Python
so extensions which have a binary dependency on Python 3.11 don't
attempt to install in a Blender built with a newer Python version.
Details:
- Extensions from incompatible Python versions are not listed.
- Python versions are extracted from wheel names.
- An extension may include wheels for multiple Python versions,
only the compatible wheels will be installed.
- Links may include a "python_versions" field which is checked
when dropping into Blender.
- JSON generated by the "server-generate" command include the:
"python_versions" field for extensions that include wheels.
- The "python_versions" field is optional, when omitted no version
checks are performed.
Also correct watch_test make target.
Ref #128750.
Example:
Step is 3
Action starts at 1, so the action will try to export frames 1 / 4 / 7 / 10, etc...
But full object backing is enable, and scene starts at 0.
So cached data are on frame 0 / 3 / 6 / 9 / 12, etc...
When we are trying to export the action on armature after the full bake on empty, we are trying to retrieve frame 1, but cache was on 0 / 3 / 6 / 9
error log will go to stderr, and others to stdout
A new parameter in operator to set the loglevel from command line bpy.ops.export_scene.gltf(loglevel=logging.INFO)
If not set from the ops, value is -1, and is set, as before, from the bpy.app.debug_value
Python wheels from extensions were not being removed after
install/uninstall in some cases - although installing an extension
afterwards that used wheels would recalculate deps & remove them.
- Installing an extension didn't include the extension in the
compatibility-cache, causing uninstalling not to remove deps.
- Uninstalling an extension wasn't re-calculating the deps,
leaving them as-is.
Always write the compatibility-cache after installing and uninstalling
so changes are detected & handled.
Building an extension when the manifest didn't define a "type"
would assert instead of reporting the missing field.
Return earlier when there are errors to prevent the assertion.
On Windows an entire directory may be locked when any files inside it
are opened by another process. This can cause operations that
recursively remove a directory (uninstalling & updating) to fail
with a partially removed extension.
The case of uninstalling was already handled, where failure to remove
a directory would stage the extension for later removal.
In the case of updating however, the user could be left with a broken
(partially removed) extension where some files were removed, as the
directory was locked, the update would fail to extract new files.
Address this issue by renaming the directory before recursive removal.
The following logic has been implemented:
- If any files in the directory are locked, renaming will fail.
So even though the operation fails the extension is left intact.
- If renaming succeeds, it's possible to apply the update.
While it's possible (albeit unlikely) recursive removal fails,
which could be caused by file-system permissions issues corruption or
a process could open a file between rename & removal.
In this case the renamed directory is staged for later removal.
Other changes:
- Resolve a related problem where the user could install an
extension previously staged for removal, now installing an extension
ensured it's not removed later.
This would occur if uninstalling failed, the user resolves
directory-lock, uninstalls again, then re-installs the extension.
- When an extension fails to be removed, don't attempt to remove
user configuration for that extension.
Prefer to keep the extension & it's settings in their "current state"
if it can't be removed.
Do not report error when local repo does not have manifest and we are
asking for remote repositories.
If the errors list is filled with any error the operation is considered
failure.
Ref: !127360
