fix(plugin_utils): prioritize installed package import over relative cwd path in plugin loader

[taran-dev4u]

Fixes #2415.

Problem

In flexmeasures/utils/plugin_utils.py, register_plugins previously used if not os.path.exists(plugin) to decide whether an entry in FLEXMEASURES_PLUGINS was an installed package or a file path.

When a plugin was installed in the environment (e.g. my_plugin), but the server was launched from a directory containing a same-named folder (my_plugin/), os.path.exists("my_plugin") returned True. The loader would then re-execute __init__.py as a fresh module object, overwriting sys.modules[plugin_name] and leaving submodules pointing to the old module object. This created an empty Blueprint during registration, causing all plugin routes to 404 and CLI groups to be empty.

Solution

1. Differentiate explicit file paths (containing /, \, os.sep, absolute paths, or starting with .) from bare package names.
2. For bare package names, first attempt to import via importlib.import_module(pkg_name).
3. If ModuleNotFoundError is raised and a local folder exists, fall back to relative path loading with an explicit warning.
4. Added unit test suite flexmeasures/utils/tests/test_plugin_utils.py covering installed package prioritization, explicit file paths, fallback behavior, and error handling.

[read-the-docs-community]

Documentation build overview

📚 flexmeasures | 🛠️ Build #34255838 | 📁 Comparing 464e2e1 against latest (7923b8a)

  🔍 Preview build  

15 files changed · ± 14 modified · - 1 deleted

± Modified

• changelog.html
• configuration.html
• genindex.html
• py-modindex.html
• _autosummary/flexmeasures.api.common.responses.html
• _autosummary/flexmeasures.api.common.utils.api_utils.html
• _autosummary/flexmeasures.api.v3_0.html
• _autosummary/flexmeasures.data.html
• _autosummary/flexmeasures.data.models.planning.storage.html
• _autosummary/flexmeasures.data.utils.html
• and 4 more...

- Deleted

• _autosummary/flexmeasures.api.v3_0.utils.html

[nhoening]

We already opened #2419 - is this PR doing things differently or better?

[taran-dev4u]

Hi @nhoening, thanks for pointing that out! I reviewed PR #2419 by @Flix6x — it is more comprehensive, specifically in handling namespace packages via ind_importable_package and providing full end-to-end route registration test coverage with submodules. PR #2443 was an independent exploration of #2415; since #2419 thoroughly resolves the issue, I will close this PR in favor of #2419. Thanks!