Specifying Extensions in the metadata?

[iandol]

Description

Currently, to use extensions we use the CLI command to install them, and then specify them in the metadata. I just tried Typst where the #import command will install a package the first time it is used, making the document "self-contained". Why can't specifying an online extension in the metadata automatically install them without any further action, so for example:

filters:
  - kapsner/authors-block

…would run quarto add kapsner/authors-block if it wasn't installed yet, then use it.

[cscheid]

Why can't specifying an online extension in the metadata automatically install them without any further action

A number of reasons, including

• we don't want quarto to install third-party code without explicit user consent.
• we don't currently want the maintenance burden of handling packages (and, inevitably, their versions and dependencies).

We can have a separate discussion about the merits of this decision. The current model serves the goals we have in mind, and since package code is meant to b stored with quarto projects in version control, the prompting only happens once, for the first time a package is ever installed in the context of a particular document. We think that's an acceptable tradeoff presently.

[iandol]

Fair enough, thank you for consideration.

Within the Pandoc community we have also had many projects that aim to make the document itself "sufficient" for generating a final work. Panzer, Pandocomatic, and many others have enabled a writer to use document metadata to fully specify a final compiled end-work. This fits other tools, like the excellent writing app Scrivener which compiles to a single document, not a collection of files in a folder. Many potential writers are not geeks, and versioned repositories, pushing or pulling folders etc. itself is already a huge challenge. Allowing a markdown document to be "sufficient" can reduce some of these barriers to a simple terminal command, and at least gives a flexible alternative.

Quarto has focussed on the "folder" as being the minimum unit of a work. I'm not convinced that asking a user to paste a terminal command is "better" than using metadata for security, in both cases something gets installed in their system without them knowing anything about that extension or its code, but you can argue pasting a terminal command is an extra manual step at least. Having a central repository is indeed an extra challenge. But using github and its release system for packages/extensions does substantially reduce this burden on you (which is basically what you are doing now with extensions, sans the release versioning). Nevertheless I appreciate you have a design philosophy and prefer to stick to it.

[mcanouil]

It's not just pasting. The command prompt twice the user to download and install an extension.
If users don't look at the code of the extension, it's on them as they agreed twice.

[iandol]

Right, I forgot about that. Indeed, this would totally block a one-shot compile/render workflow, unless this was interactive (which at least for tools like Scrivener, is not the case).