Closed shimpeko closed 1 year ago
Base: 47.68% // Head: 31.37% // Decreases project coverage by -16.30%
:warning:
Coverage data is based on head (
c3df436
) compared to base (06b571f
). Patch coverage: 79.26% of modified lines in pull request are covered.:exclamation: Current head c3df436 differs from pull request most recent head cefcf25. Consider uploading reports for the commit cefcf25 to get more accurate results
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
@radeklat Can I get your thought on this?
I'd like to change the plugin discovery method to ignore dependent distributions.
The current implementation of plugin discovery, which uses package metadata, discovers plugins from all installed distributions including dependent distributions. For example, when plugin_a depends on plugin_b it will load commands from both plugin_a and plugin_b, even when a user has installed only plugin_a explicitly. And it can cause a naming collision when plugin_a and plugin_b provide commands with the same name.
To solve the above issue I'd like to implement a new plugin discovery approach that uses a list of distributions (plugin names) defined in pyproject.toml
(which we've discussed offline). This new plugin approach is not an automatic discovery and users need to list up plugins they want to use in pyproject.toml
(in addition to installing the plugin).
With the new plugin discovery approach, I still want to keep using the metadata, to point to package name which contains the command in a plugin.
Another option is using the tool.delfino.disable_plugin_commands
to solve command naming collision. But I think it is not ideal to ask users to solve naming collisions caused by dependent distributions (that are installed implicitly).
@shimpeko Do you have any specific example use case for plugins depending on other plugins? I think that should be discouraged. Perhaps a plugin that would like to enhance a different plugin? For example let's say there is delfino-common
plugin that has a command typecheck
. And you would like to create a delfino-cookpad-common
, which depends on delfino-common
, has typecheck
that wraps around delfino-common.typecheck
and modifies it?
Merged as part of #42
closes https://github.com/radeklat/delfino/issues/30
Introduce a plugin system which uses the distribution metadata, entry point, as discovery method.