4 ms·

In the llm project, plugins can modify the command line arguments, so it's not that simple.

• simonw 1y ago
  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#register-commands-cli https://llm.datasette.io/en/stable/plugins/plugin-hooks.html...
  • deleted 1y ago
    [deleted]
  • pests 1y ago
    Could you cache the help doc after first full loaded run and only regenerate when new plugins are added / updated?
    • simonw 1y ago
      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.
      • Inufu 1y ago
        In that case the CLI only needs to import the plugin that defined that sub command, not all plugins?
        • simonw 1y ago
          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.
          • peterfirefly 1y ago
            > 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.
  • zahlman 1y ago
    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)