WM: correct logic for resetting add-ons & caching meta-data
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]: 497bc4d199
This commit is contained in:
@@ -536,8 +536,9 @@ def reset_all(*, reload_scripts=False):
|
||||
"""
|
||||
import sys
|
||||
|
||||
# initializes addons_fake_modules
|
||||
modules_refresh()
|
||||
# Ensures stale `addons_fake_modules` isn't used.
|
||||
modules._is_first = True
|
||||
addons_fake_modules.clear()
|
||||
|
||||
for path, pkg_id in _paths_with_extension_repos():
|
||||
if not pkg_id:
|
||||
|
||||
Reference in New Issue
Block a user