Replies: 1 comment 1 reply
-
|
One thing that I tried (but did not work) was to have AddonGroup inherit from |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi. Me again, with another question related to enabling a plugin architecture.
I have a CLI tool (cloup + click) that has multiple levels of "hard-coded" commands.
I would like to make it possible to have "plugin" commands that are distributed separately from the main tool, to only selected users. I am therefore trying to figure out a way to enable (sub-)commands to have a mix of hard-coded sub-commands and "discoverable" sub-commands.
For example the tool may support
But the user can install a subcommandplugin.py files inside ~/.mycli/plugins/command1/, which would then enable
And similarly, a pluginY.py file inside ~/.mycli/plugins/ would then enable
I have been able to make it work when introducing a special sub-command that enables a list of plugins, such as
with the following
But I don't like the need for this extra "addons" sub-command.
Any recommendation?
BTW, with cloup, I'd add any "discovered" plugin in a specfic section, but this would be alongside other hard-coded sections.
Thanks in advance
NB. to be clear, I've avoided talking about "lazy-loading", because it's not really something I need or care about. If they're lazy-loaded, that's fine, but it's more important to me that they are discoverable at run-time and can be listed (alongside hard-coded commands) in the --help section
Beta Was this translation helpful? Give feedback.
All reactions