pythreejs loads unnecessarily

[jf---]

When using compas_viewer (which seems to be improving a lot...) I noticed that an unrelated module it loaded (pythreejs, related to compas_notebook). Loading an unrelated library (I've worked with pythreejs quite a bit, its pretty slow to load) could hinder a faster startup time of compas_viewer

---

/compas_libigl/docs/examples/example_geodistance_multiple.py
None
PyThreeJS Model elements registered.
PyThreeJS SceneObjects registered.
Color(red=0.154, green=0.680, blue=0.504, alpha=1.000)
Color(red=0.304, green=0.765, blue=0.420, alpha=1.000)
Color(red=0.142, green=0.526, blue=0.556, alpha=1.000)

[tomvanmele]

hi jelle,

yes indeed. the greedy mechanism of the plugin system is not ideal.

am working on a solution...

[tomvanmele]

btw, regarding this

@petrasvestartas please remove imports of functionality in compas_libigl.__init__.py
@Licini we should remove from .viewer import Viewer from both compas_viewer.__init__ and compas_notebook.__init__, because it triggers all sorts of things...

@gonzalocasas i would like to propose a change to the plugin system in which we are more precise about the pluggable categories, and in which we provide category meta data in the __all_plugins__ variable so they can be loaded more selectively...

[gonzalocasas]

For COMPAS 3.x, we should/could rework the discovery mechanism a bit and bring it up to date to 2025. The current approach was needed because of IronPython and the lack of support for decently modern metadata discovery, but things could be improved once we drop ironpython support

[tomvanmele]

i think that even without Python 3 functionality by simply making __all_plugins__ a dict with plugin categories as keys, we could improve the discovery significantly. this would allow us to only load relevant plugins instead of blindly loading everything as we do now. the required change would be minimal. i will make a draft so we can discuss based on a real example...

[jf---]

@tomvanmele & @gonzalocasas

please remove imports of functionality in compas_libigl.init.py

one way to address this is to have a spec or best practice document on how plugins would be best implemented.
could that be an idea for the near term?

support for decently modern metadata discovery

since PEP 621, metadata like name, version, authors, description, etc. are now declared declaratively in pyproject.toml.
is that what you refer to by modern metadata discovery?

from importlib.metadata import distributions

def find_dependents(target_dep):
    print(f"Packages depending on '{target_dep}':")
    for dist in distributions():
        try:
            requires = dist.requires or []
            if any(target_dep.lower() in req.lower() for req in requires):
                print(f"- {dist.metadata['Name']} ({dist.version})")
        except:
            continue

# Example
find_dependents("numpy")

but things could be improved once we drop ironpython support

💎will that take place with compas >= 3.0?

[tomvanmele]

one way to address this is to have a spec or best practice document on how plugins would be best implemented.
could that be an idea for the near term?

yes, this should indeed be added to the dev docs

[tomvanmele]

dropping support for ironpython, hard, is indeed what will happen in COMPAS 3

[tomvanmele]

regarding plugin discovery, i don't know what @gonzalocasas has in mind, but already within the current infrastructure, and without breaking compatibility, i think we could already scope the discovery of plugins by relevant context and category, such that plugins are not loaded unnecessarily...