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
-
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