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
Since [0] missing repository directories printed a warning on startup.
When checking for blocked extensions on startup, skip directories
that don't exist & don't print any warnings if the repository data
hasn't been downloaded.
[0]: 656fe6d3e4
When deleting files on WIN32, open files cannot be removed.
This is especially a problem for compiled Python modules which
remain open once imported.
Previously it was not as common for add-ons to include compiled Python
modules however with extensions supporting Python-wheels,
it's increasingly likely users run into this.
Workaround the problem by:
- Scheduling the files for removal next time Blender starts.
- Rename paths that cannot be removed to avoid collisions when
the paths is reused (re-installing for example).
This is supported for:
- Extensions.
- Python wheels.
- Legacy user add-ons.
- App-templates.
Details:
- On startup, a file exists that indicates cleanup is needed.
In the common case the file doesn't exist.
Otherwise module paths are scanned for files to remove.
- Since errors resolving paths to remove could result in user data loss,
ensure the paths are always within the (extension/addon/app-template)
directory.
- File locking isn't used, if multiple Blender instances start at the
same time and try to remove the same files, this won't cause errors.
Even so, remove the checking file immediately avoid unnecessary
file-system access overhead for other Blender instances.
Also resolves#125049.
Expose arguments to use when creating a Python sub-process.
Python could fail to start when loaded in a customized environment,
with PYTHONPATH set for e.g. Blender ignores these and loads but a
Python sub-process attempts to use these environment variables which
may point to incompatible Python versions.
Resolve the root cause of #124731.
Workaround: `[ASN1] nested asn1 error` error when making HTTPS
connections on systems with certificates that OpenSSL cannot parse
are installed.
This is a general issue with Python, resolve by applying a proposed
fix [0] to the extensions Python process at run-time.
(this doesn't impact Blender's Python run-time).
The down side is HTTPS connections will only work for extensions
on systems with this problem so this needs to be resolved by Python
long term.
While any changes to Python's SSL checks is worth avoiding,
this simply skips SSL certificates in the windows store that OpenSSL
can't parse instead of failing all SSL connections.
See related issues:
- https://github.com/python/cpython/issues/79846
- https://github.com/openssl/openssl/issues/25023
[0]: https://github.com/python/cpython/pull/91740
Ref !124943.
Support blocking extensions so there is a way for the maintainers of
the remote repository to notify the user if one of their installed
extensions blocked along with a reason for blocking.
Blocked extensions cannot be installed from the preferences or by
dropping a URL.
When an installed & blocked extension is found:
- An icon int the status bar shows an alert,
clicking on the icon shows the blocked extensions.
- The extensions preferences show a warning.
- The extensions & add-ons UI shows an alert icon
and "details" section shows the reason.
Details:
- Blocked & installed extensions are shown first in the installed
extensions panel.
- The internal "install" logic prevents downloading & installing
blocked extensions.
- Blocked extensions can still be downloaded & installed from disk.
- The "list" command includes an error message if any installed
extensions are blocked.
- The "server-generate" command can optionally take a configuration
file that includes the blocklist for the generated JSON.
See design #124954.
Core extensions should have their bugs reported as any other issue in
Blender.
This PR removes their "Rrport a Bug" link.
I left the link only for glTF since it has its own tracker. But I
wouldn't mind removing it as well.
Ref: !125218
When dropping an extension from extensions.blender.org which is
still in the review queue - an error was shown making it seem like
the extension was not compatible with the system.
Adjust wording to clarify that it was not found in the remote repo
which can be caused by it not being part of the repository or when
it's incompatible.
Resolves#125046.
When "bl_info" was on the first line, the legacy add-on would not
install. Correct the check which would also incorrectly detect legacy
add-ons when "bl_info" wasn't found at all.
Regression in [0] caused extensions checks used the same directory & URL
for all remote repositories when checking for updates on startup.
[0]: d2049f0aa7
When the user attempted to install a previously enabled add-on as an
extension after enabling online access and *without* viewing extensions,
installation would fail.
Resolve by adding a check that the remote repository data is available,
adding a button to refresh remote repositories if it's not.
The logic to handle disabling, upgrading & re-enabling extensions
incorrectly assumed all installed add-ons were enabled.
Resolve by only using this logic on installed & enabled add-ons.
When Blender started with an extension enabled from a repository that
referenced a directory that didn't exist - creating the directory
and extensions would fail to import the extension.
This happened because the missing state of the module was cached.
Resolve by clearing Python's path cache for the repository after
running install actions which may have created the directory.
Also run importlib.invalidate_caches() when manually refreshing local
extensions to ensure modules cached as missing can be imported if
they have become available.
As each extension has it's own package, any modules it includes must be
imported as sub-modules. Warn if extensions are including themselves
in the sys.path as this breaks name-spacing of extensions.
Show these warnings in the add-on & extensions UI.
When the repository is owned by another Blender session,
support removing the file-system lock.
This is accessible from a menu in the repository popover.
This is needed if Blender exits unexpectedly while a repository
is being modified (typically install/upgrade).
Addresses #122135.
While this wasn't likely to cause any problems in practice,
using the sub-command "build --split-platform" with a platform
containing any characters that need escaping would have produced a TOML
with invalid syntax.
Add a utility function that's guaranteed to create a valid TOML string.
Various minimal grammar changes in the new Extensions system. For
example changing "Please turn Online Access on the System settings" to
"Please turn Online Access on in the System settings"
Pull Request: https://projects.blender.org/blender/blender/pulls/124262
The functionality of the Bone Selection Sets add-on is now integrated
into Blender itself. Rigify has been updated to no longer check for the
add-on, but just assume that the functionality is available.
The keymap is still the same, and so are all the class names. This
ensures that there are no conflicts when people still have the old
add-on enabled somehow. And there is versioning code to remove the
'add-on enabled' state so that Blender won't complain it cannot find it
any more.
Compared to the add-on, the following changes are made:
- The 'bone' icon has been removed from the list of available selection
sets. It was the same for each entry anyway, and thus didn't provide
any information.
- The code has been split up into multiple files, with the UI elements
in `scripts/startup/bl_ui/properties_data_armature.py` and the
operators in `scripts/startup/bl_operators/bone_selection_sets.py`.
- Helper functions and classes are prefixed with `_` to indicate that
they are not part of any public API.
- The `Operator` helper subclasses have been transformed to mix-in
classes. This way the only subclasses of `Operator` are the actual
operators.
- Comments & descriptions have been updated for clarity & consistency.
This commit contains code by the following authors, ordered by number of
commits in the original add-on repository, highest first:
Co-Authored By: Ines Almeida <britalmeida@gmail.com>
Co-Authored By: Sybren A. Stüvel <sybren@stuvel.eu>
Co-Authored By: Campbell Barton <ideasman42@gmail.com>
Co-Authored By: meta-androcto <meta.androcto1@gmail.com>
Co-Authored By: Demeter Dzadik <Mets>
Co-Authored By: lijenstina <lijenstina@gmail.com>
Co-Authored By: Brecht Van Lommel <brechtvanlommel@gmail.com>
Co-Authored By: Aaron Carlisle <carlisle.b3d@gmail.com>
For the full history see the original add-on at:
https://projects.blender.org/blender/blender-addons/commits/branch/main/bone_selection_sets.py
Reviewed On: https://projects.blender.org/blender/blender/pulls/124343
- Suppress pylint warnings via comments or be minor changes.
- Any errors disabling add-ons before upgrading or uninstalling are now
reported to the operators.
- Disable cyclic import warning is it's impractical to resolve.
- Enable useless-suppression warning.
