Closed jkrumbiegel closed 1 month ago
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.
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.
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
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.
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.
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.
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).
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 withknitr::pandoc_to()
, as one example.