Commit Graph

11 Commits

Author SHA1 Message Date
Campbell Barton
67ddb0e1a5 Extensions: detect external changes on startup & loading preferences
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.
2024-07-01 15:08:14 +10:00
Campbell Barton
350b8047c6 Extensions: move the wheel_manager out of the extensions add-on
Move wheel management to a generic private module, prepare addon_utils
to handle changes to repositories on load (needed to resolve #123645).
2024-07-01 10:07:16 +10:00
Campbell Barton
ac8da6c72e Extensions: move junction_module to a private location
bpy_extras is part of the public API where as the junction_module
is part of the internal implementation of extensions.
Move to "_bpy_internal".
2024-06-28 14:30:11 +10:00
Damien Picard
4719ce5d56 I18n: Allow translation of extension tags and permissions
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
2024-06-14 16:35:54 +02:00
Dalai Felinto
77a69d04f2 Extensions: Changes to the translatable tags table
* 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.
2024-06-13 10:17:10 +02:00
Campbell Barton
eaa3f4c034 Cleanup: double-quote plain text strings 2024-06-12 10:56:12 +10:00
Dalai Felinto
188b6fd3d0 Extensions: List of tags to be used for translation
Internal module used for translation.

Pull Request: https://projects.blender.org/blender/blender/pulls/123069
2024-06-11 17:42:56 +02:00
Campbell Barton
949dfbfaa8 Cleanup: Python script formatting
- Double quotes for strings.
- Trailing commas when wrapped lines.
2024-06-06 11:26:28 +10:00
Campbell Barton
0c4117f24a Linux: only allow registering file association for portable builds
Disable registering file associations on Linux for system-installations
and snap packages, details in code-comments.
2024-04-30 15:48:46 +10:00
Campbell Barton
4e8b24f1d1 Cleanup: spelling in comments & punctuation 2024-04-19 15:57:06 +10:00
Campbell Barton
9cb3a17352 Linux: freedesktop support for file type association
Support freedesktop file association on Linux/Unix via the command line
arguments: `--register{-allusers}` `--unregister{-allusers}` as well
registration actions from the user preferences.

Once registered, the "Blender" application is available from launchers
and `*.blend` files are assoisated with the blender binary used for
registration.

The following operations are performed:

- Setup the desktop file.
- Setup the file association & make it default.
- Copy the icon.
- Setup the thumbnailer (`--register-allusers` only).

Notes:

- Registering/unregistering for all users manipulates files under
  `/usr/local` and requires running Blender as root.
  From the command line this can be done using `sudo`, e.g.
  `sudo ./blender --register-allusers`.
  From the GUI, the `pkexec` command is used.

- Recent versions of GNOME execute the thumbnailer in a restricted
  environment (`bwrap`) requiring `blender-thumbnailer` to be copied
  into `/usr/local/bin` (synlinks don't work).
  So thumbnailing copies the binary rather than linking and only works
  when registering for all users.

Ref !120283
2024-04-18 11:19:00 +10:00