Addon fails to register after update: check_module() ignores version pin, stale SpoutGL install crashes register()

[gyomh]

Disclosure

This issue was diagnosed and drafted with the help of an AI coding assistant (Claude) — it
reproduced the crash live in a running Blender session via MCP, traced it to the SpoutGL
version mismatch below, and drafted this write-up and patch. I reviewed and validated the
fix before posting.

For full transparency (yes, this is getting recursive): I then asked the AI to add this
disclosure paragraph after it had already written the issue, and then asked it to make the
disclosure paragraph funnier after that. So if this reads like a Wikipedia "citation needed"
chain, that's why. The bug and the fix are real either way — feel free to hold the patch to
the same standard you'd hold any other PR.

This part is the real me writing: I asked Claude to be a bit funny about it. It's not,
at all... but hey, maybe the world isn't so f***ed up right now.

Bug

After updating the addon (or on a machine that already had an older SpoutGL installed
from a previous version of this addon), register() throws:

Error: 'SpoutGL._spoutgl.SpoutReceiver' object has no attribute 'getSenderList'

Root cause

pip_importer.check_module() only checks whether the module is importable — it never
compares the installed version against the version pin declared via
add_package(Package(name, version="==0.1.1", ...)):

def check_module(package):
    ...
    try:
        module = sys.modules[package.module]
        if hasattr(module, '__path__'):
            package._location = module.__path__[0]
            package._registered = True   # <-- marks "installed" regardless of version
    except KeyError:
        ...

So if a stale SpoutGL==0.0.6 (which predates getSenderList(), added in 0.1.x) is already
on sys.path, auto_install_packages() never upgrades it, and register() crashes as soon
as it tries to enumerate senders.

Secondary issue (makes this harder to debug)

__init__.py::register() only wraps the operators/ui/keys import+register in
try/except ModuleNotFoundError. Any other exception (like the one above) propagates up
uncaught, but pip_importer.register() has already run and registered its own operator/
preferences classes. Since Blender's addon_enable then reports the addon as not enabled,
any subsequent retry immediately fails on:

Error: register_class(...): already registered as a subclass 'Pip_Update_package'

...which completely hides the real error (the SpoutGL version mismatch) behind a confusing,
unrelated one. A user hitting this has no way to see the actual crash without manually
unregistering the orphaned classes first.

Suggested fix

1. In check_module, compare the installed version to package.version (e.g. via
   importlib.metadata.version(package.module)) and only set _registered = True if it
   satisfies the pin — otherwise let auto_install_packages() reinstall/upgrade it.
2. In __init__.py::register(), catch broader exceptions around the whole registration
   block, call unregister() to roll back any partially-registered classes, and re-raise
   (or report) the original exception so the real cause is visible on the next attempt.

Happy to open a PR with both fixes if useful.

Suggested patch (pip_importer.py)

+from importlib import metadata as importlib_metadata
+
 def check_module(package):
     import sys, site

     p = site.USER_SITE
     if p not in sys.path:
         sys.path.append(p)
     try:
         module = sys.modules[package.module]
         if hasattr(module, '__path__'):
             package._location = module.__path__[0]
-            package._registered = True
+            package._registered = _version_satisfies(package)

     except KeyError:
         package._registered = False
         try:
             __import__(package.module)
             get_package_show(package)
+            package._registered = _version_satisfies(package)
         except ModuleNotFoundError:
             pass

     return package._registered

+def _version_satisfies(package):
+    if not package.version:
+        return True
+    try:
+        installed = importlib_metadata.version(package.name)
+    except importlib_metadata.PackageNotFoundError:
+        return True  # can't verify, don't block on it
+    required = package.version.lstrip("=<>~! ")
+    return installed == required

[maybites]

Review of Dependency Registration and Version-Detection Issues

Thanks for the thorough writeup (and for the transparency about the process—appreciated either way, the diagnosis checks out).

I verified both claims against the current code:

• check_module() does set _registered = True for any importable module regardless of version—confirmed at pip_importer.py:60-64.
• getSenderList() is genuinely only called at fbs/spout/SpoutDirectory.py:23 and postdates the 0.1.x series, so the crash is real for anyone carrying over a stale SpoutGL install.

The masking bug is also real:

• pip_importer.register() registers its operator/preferences classes in __init__.py:36.
• This happens before the try/except ModuleNotFoundError block around the operators/ui/keys import at __init__.py:48-67.
• Any exception besides ModuleNotFoundError escapes uncaught.
• Blender then marks the add-on as disabled, but the pip_importer classes remain registered.
• On the next enable attempt, Blender fails on:

register_class(...): already registered as a subclass 'Pip_Update_package'

instead of reporting the original underlying error.

Impact Beyond Spout

It's also worth noting that this issue is not Spout-specific.

Both:

• syphon-python==0.1.0
• cyndilib==0.0.5

follow the identical check_module() / auto_install_packages() path (__init__.py:43,45), meaning they are exposed to the same "stale install silently reported as fine" behavior.

Any fix should therefore apply across all three dependencies. Your patch naturally achieves that since it targets the shared helper rather than a package-specific code path.

UI Suggestion

One additional UI-level improvement is worth considering.

With the version check in place, a stale installation will now correctly leave _registered = False, which is the right behavior. However, in PiPPreferences.draw() that state currently renders identically to a package that has never been installed (pip_importer.py:241):

• Status: "Not installed"
• Install button shown

As a result, a user with, for example, SpoutGL 0.0.6 installed will see the exact same UI as someone on a completely clean system. The distinction between:

• package absent, and
• package present but outdated

remains hidden.

Since the primary goal of this fix is to expose version mismatches instead of silently accepting them, it would be beneficial to surface the detected version directly in the preferences panel.

For example:

row.label(
    text=f"Outdated ({installed_version} → {package.version})",
    icon="CANCEL"
)

rather than the generic "Not installed" label when a version is present but does not satisfy the required pin.

A clean way to support this would be to preserve the detected version in _version_satisfies() instead of discarding it, storing it on the package instance for use by the UI.

Recommendation

I'm happy to have you open the PR.

Ideally, it would include:

1. Version-aware dependency validation in the shared helper.
2. The registration/unregistration fix that prevents the real startup error from being masked.
3. The preferences-panel improvement to distinguish outdated installations from missing installations.

That said, if you'd prefer to keep the scope limited to the two functional fixes and leave the UI messaging improvement for a follow-up PR, that's perfectly reasonable as well.

[gyomh]

While testing this locally (Windows, Blender 5.0), I hit a related edge case worth flagging separately.

check_module() does sys.path.append(site.USER_SITE), which gives Blender's bundled site-packages priority over the user site-packages that pip actually installs into (since the bundled folder is normally read-only). In my case, a stale SpoutGL 0.0.6 had at some point ended up directly inside Blender's bundled python/lib/site-packages (likely from running Blender elevated once). Even after pip install --upgrade SpoutGL==0.1.1 succeeded and Blender was fully restarted, the addon kept loading the old bundled copy — the version check in this PR correctly reported it as "Outdated" instead of silently accepting it or crashing, but the upgrade never actually took effect until I manually deleted the stray copy from the bundled directory (needed elevated permissions).

Not something this PR needs to solve, but a cheap mitigation for anyone else who hits it: swapping to sys.path.insert(0, site.USER_SITE) would make the user-installed (and therefore always up-to-date) copy take priority over any stray bundled one. Happy to open a separate PR for that if useful, or leave it as a known-issue note.