The other thing we might want to do is audit our plugins for too-eager imports. Ideally scanning the entry point would avoid importing most of the plugin implementation.

The other thing we might want to do is audit our plugins for too-eager imports. Ideally scanning the entry point would avoid importing most of the plugin implementation.

I'm not following, scanning the entry point?

When a plugin is imported, just to be added to the list of conda x, it should not do very much work. Including importing things.

A plugin author might want to arrange a plugin with separate folders myplugin/cli and myplugin/implementation so that "import myplugin.cli" doesn't import whatever dependencies "myplugin.implementation" uses to do its thing. Inside "myplugin.cli:do_the_plugin()", import "myplugin.implementation".

Then unrelated commands remain fast.

Firefox used to say "these extensions are slowing down your browser" and tell you how long each one took to load. Then you could decide whether to continue to use those extensions. It also has a safe mode to avoid loading all extensions.

I see, lazy loading plugins, but I don't see how this works with pluggy as it uses importlib as the central system to load entrypoints based plugins which loads plugins with the import system. I'm not sure how to achieve this given these constraints. I'll take a look at it tomorrow.

It depends on the type of the plugin.

For conda_subcommands it is simple. Image some subcommand uses sqlalchemy.

A. someplugin.py

import sqlalchemy
def custom_command():
    sqlalchemy.do_a_thing()

@plugins.hookimpl
def conda_subcommands(self):
    yield CondaSubcommand(
        name="custom",
        summary="test custom command",
        action=self.custom_command,
    )

B. anotherplugin.py

def custom_command():
    import sqlalchemy
    sqlalchemy.do_a_thing()

@plugins.hookimpl
def conda_subcommands(self):
    yield CondaSubcommand(
        name="custom",
        summary="test custom command",
        action=self.custom_command,
    )

The second plugin is faster.

Authors would be more likely to do this accidentally, by having an __init__.py that imports a bunch of things sitting between your entry points hook and the @plugins.hookimpl call.

It depends on the type of the plugin.

For conda_subcommands it is simple. Image some subcommand uses sqlalchemy.

A. someplugin.py

import sqlalchemy
def custom_command():
    sqlalchemy.do_a_thing()

@plugins.hookimpl
def conda_subcommands(self):
    yield CondaSubcommand(
        name="custom",
        summary="test custom command",
        action=self.custom_command,
    )

B. anotherplugin.py

def custom_command():
    import sqlalchemy
    sqlalchemy.do_a_thing()

@plugins.hookimpl
def conda_subcommands(self):
    yield CondaSubcommand(
        name="custom",
        summary="test custom command",
        action=self.custom_command,
    )

The second plugin is faster.

Authors would be more likely to do this accidentally, by having an __init__.py that imports a bunch of things sitting between your entry points hook and the @plugins.hookimpl call.

Yeah, I get that, import-time side effects have a downside. For subcommands we could allow to optionally pass a dotted import path as the action parameter and lazy-import it when we need it, to move the moment of loading to later in the stack.

Thanks @jezdez, this is a much better experience than the older behavior.

Did we fake a working plugin too as long as we're in here?

Did we fake a working plugin too as long as we're in here?

Nah, but it's a good idea to do that in a separate PR.