Handling of ModuleImporter

[LecrisUT]

Trying to get an understanding with @happz on the issues in #2922 (comment)

The main issue is that not all IDEs handle the ModuleType well, PyCharm for example fails to auto-complete, while the type-checkers seem to need special workarounds. I've tried out an alternative design in: https://github.com/LecrisUT/optional_imports

But the more I think about it, what are the purpose of using ModuleImporter over just try import in each relevant module?

[happz]

But the more I think about it, what are the purpose of using ModuleImporter over just try import in each relevant module?

Mostly my dislike of constructs like https://github.com/teemtee/tmt/blob/main/tmt/steps/provision/testcloud.py#L42, https://github.com/teemtee/tmt/blob/main/tmt/steps/provision/testcloud.py#L45, https://github.com/teemtee/tmt/blob/main/tmt/steps/provision/testcloud.py#L59 and chance every plugin developer would need to employ try/except ImportError and raise exception (https://github.com/teemtee/tmt/blob/main/tmt/steps/provision/testcloud.py#L92). I would very much like to find a solution that would add a bit more shared code and prevent plugin developers from reinventing the wheel.

Maybe a completely different approach would be more success.

[LecrisUT]

🤔 What about decoupling the plugins into their own sub-projects? That way they don't need to try import at all. They could live in the same repo under subdirectories and share the same versioning. Packit supports building monolith repo although there are no dependency structure for copr builds