Just FWIW, a trick that I'm planning to use for PAPER: first I make separate actual commands — `paper-foo`, `paper-bar` etc. that are each implemented as separate top-level scripts that can import only what they need. Later, the implementation of `paper foo` has the main `paper` script dynamically look up `paper-foo`. (Even a `subprocess.call` would work there but I'd like to avoid that overhead)
It's not just help - the plugins need to be imported so the root level CLI tool knows what to do if you type "llm subcommand ..." where that subcommand is defined by a plugin.
It doesn't know which plugin defines a subcommand until it imports the plugin's module.
I'm happy with the solution I have now, which is to encourage plugin authors not to import PyTorch or other heavy dependencies at the root level of their plugin code.
> It doesn't know which plugin defines a subcommand until it imports the plugin's module.
That might be considered a design mistake -- one that should be easy to migrate away from.
You won't need to do anything, of course, if the lazy import becomes available on common Python installs some day in the future. That might take years, though.
