Accessing quarto metadata programmatically via QuartoNotebookWorker

[jkrumbiegel]

Now that we have the expand extension pipeline, I was thinking that downstream packages might want to expand differently depending on, for example, the output format that quarto renders to. I think that's different from the loading hooks we currently have. So I wonder how we could make the full quarto metadata accessible, like you can access it from knitr with knitr::pandoc_to(), as one example.

[MichaelHatherly]

Stored in https://github.com/PumasAI/QuartoNotebookRunner.jl/blob/85f65102f63c2c4eac98c5cb51eed14fc2948535/src/QuartoNotebookWorker/src/NotebookState.jl#L8, so we can make an official API for that I guess.

[jkrumbiegel]

Yes, although there's currently no open way to access anything QNW-related, is there? The extension methods hook in at package load time, you couldn't easily reach that from the notebook itself. And I think we were holding off on adding any API into the notebook workspace due to it not being available in a REPL.

[MichaelHatherly]

you couldn't easily reach that from the notebook itself. And I think we were holding off on adding any API into the notebook workspace due to it not being available in a REPL.

Would only be accessed in 3rd-parth package extensions, not directly in a notebook, e.g.

module PackageNameQuartoNotebookWorkerExt

import PackageName
import QuartoNotebookWorker

function QuartoNotebookWorker.expand(::PackageName.Foo)
    opts = QuartoNotebookWorker.options() # hypothetical public API, used at runtime.
    # ...
end

end

[jkrumbiegel]

Right, ok, so it should stay that way then. One could not develop such functionality directly within notebooks is the only drawback I can see.

[MichaelHatherly]

One could not develop such functionality directly within notebooks is the only drawback I can see.

Nope, you can't. Revise ideally should just work with this fine and functionality can just be developed directly in the extension file. If that doesn't work then we should make it work.

[jkrumbiegel]

Yes for "serious" development that's true, it just adds overhead if you want to quickly try out things. I would have liked an "escape hatch" of some kind. Actually, maybe that's already possible by requiring the right UUID manually. Just thinking out loud here, I think the extension is in general the right place to do this kind of stuff.

[MichaelHatherly]

Actually, maybe that's already possible by requiring the right UUID manually.

Given the way the LOAD_PATH is done you should just be able to always do using QuartoNotebookWorker in a cell as an escape hatch if needed. (Worked for me just now).