Add error handling for rare but possible failures on installation.
- Account for the destination extension directory being a file.
- Handle the exception if renaming the temporary directory fails.
When an extension could could be removed but it's directory could be
renamed, the install operation would fail anyway.
Resolve by completing the installation when the directory can be moved.
Report as part of #129884.
Regression in [0] caused wheels with an older Python version
that used CPython's stable ABI to be considered incompatible.
Resolve using the stable ABI for version checks.
[0]: cfc10b0232
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.
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
Pull Request: https://projects.blender.org/blender/blender/pulls/130263
This operator deals specifically with add-ons, using the term extensions
is misleading as it works for legacy (non-extension) add-ons and
extensions can also be themes.
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
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.
Regression in [0] which didn't account for entering paths in the
file selector which would create paths without confirming,
warning that the "confirm" property was missing.
Entering `*.*` would create `_._` for e.g in the users CWD for example.
Ref !128568
[0]: 6dd0f6627e.
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.
* Match name with the extension ID.
* More strict double comment for optional parameters.
* Comment out tag since it is optional.
* More complete explanation for the paths_exclude_pattern.
Campbell Barton