-
|
With click I am using the "Custom MultiCommand" approach documented here in Click 7.x or here in Click 8 in order to avoid loading all commands everytime my cli is started. Since MultiCommand is not supported by cloup and the cloup.Group has different methods, I am unsure how to adapt the lazy loading approach with cloup. Has anyone tried this out or can give me a hint on how to approach this? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
|
This is an interesting question, thank you for asking! Cloup was definitely not built with this in mind. I'll look into this and come back with something.
In my experience, unless you have a really huge number of commands, importing the commands has not been an issue in terms of loading time. The real issue has always been third-party dependencies with very slow import time (e.g. youtube-dl is one of them) and the solution was to import those packages only when needed. Do you have a different experience? |
Beta Was this translation helpful? Give feedback.
-
|
Give a look to this example: https://github.com/janluke/cloup/tree/lazy-loading-example/examples/lazy_loading. The idea is that rather than extending a MultiCommand, I define proxies (LazyCommand and LazyGroup) for lazy-loaded commands. Then I use those lazy commands as if they were normal commands. The problem with this approach is that you need to be careful because any attribute/method access on the proxy which cannot be satisfied directly from the proxy itself will cause the command to be loaded. So if you go for this approach, I suggest to put logger.debug("loading module X") on each command module, similarly as I did in the example with print(). |
Beta Was this translation helpful? Give feedback.
Give a look to this example: https://github.com/janluke/cloup/tree/lazy-loading-example/examples/lazy_loading.
The idea is that rather than extending a MultiCommand, I define proxies (LazyCommand and LazyGroup) for lazy-loaded commands. Then I use those lazy commands as if they were normal commands.
The problem with this approach is that you need to be careful because any attribute/method access on the proxy which cannot be satisfied directly from the proxy itself will cause the command to be loaded. So if you go for this approach, I suggest to put logger.debug("loading module X") on each command module, similarly as I did in the example with print().