Hacker News Reader

Comment by simonw | Hacker News Reader

Yea, that's the core problem here: plugins can add new CLI subcommands, which means they all need to be loaded on startup.

https://llm.datasette.io/en/stable/plugins/plugin-hooks.html...

View on HN

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)

Could you cache the help doc after first full loaded run and only regenerate when new plugins are added / updated?

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.

In that case the CLI only needs to import the plugin that defined that sub command, not all plugins?

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.

Reply on news.ycombinator.com