Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

quarto_render(): invisibly return paths of all rendered files on success #14

Closed
alexpghayes opened this issue May 27, 2022 · 7 comments
Closed
Labels
enhancement New feature or request upstream concerns an upstream library like quarto or pandoc

Comments

@alexpghayes
Copy link

This would make it much nicer to use quarto_render() with @wlandau's targets package to produce large volumes of parameterized reports. Currently it's a bit painful to produce parameterized reports when there are multiple output formats and you would like to render to them all at once in a targets pipeline.

If there some other easy way to programmatically access the names/paths of rendered files, that would also be great.

@wlandau
Copy link

wlandau commented Jul 1, 2022

I added Quarto integration to https://github.com/ropensci/tarchetypes through new functions tar_quarto() and tar_quarto_rep(). The major challenge was to identify all the important files so that targets can tell when to re-render a project or document. The tar_quarto_files() function digs through the output of quarto::quarto_inspect() to figure this out, but I am 100% sure if I am doing it right. For standalone documents, tar_quarto_files() looks at quarto_inspect()$formats$html$pandoc[["output-file"]], etc. For projects, it looks at quarto_inspect()$files quarto_inspect()$config$project[["output-dir"]]. Am I missing anything? Are there edge cases I am not capturing, or variations on the projects or documents where the output of quarto_inspect() looks different?

As for large volumes of parameterized reports, tarchetypes::tar_quarto_rep() sets up a pipeline to render a single source document repeatedly over a grid of input parameters. tar_quarto_rep() detects the user's choice of output format from quarto_inspect(), and then it uses the format to create an output file name for each set of parameters in the grid. tar_quarto_rep() uses the output_file argument of quarto_render() to enforce the new file name, but this breaks for multiple formats because output_file cannot be of length greater than 1. Would you be open to allowing output_file and output_format specify more than one file output in quarto_render()?

@wlandau
Copy link

wlandau commented Aug 11, 2022

In fact, it would be really nice if quarto_inspect() could accept an output_format argument (which could be a vector) so Quarto could tell tarchetypes exactly which files it will generate (files which targets should track for changes). Came up in ropensci/tarchetypes#102.

@wlandau
Copy link

wlandau commented Sep 7, 2022

Another edge case came up at ropensci/tarchetypes#107. If there is a simple _quarto.yml file, then quarto_inspect("single_report.qmd") does not show the output directory where quarto_render("single_report.qmd") will store single_report.html. For integration with targets, it would be extremely helpful if quarto_inspect() could straightforwardly list all the output files, with directory paths included, that will be generated by quarto_render(). Otherwise, tarchetypes would need to emulate the output file policies of Quarto, which could change if Quarto changes.

@cderv
Copy link
Collaborator

cderv commented Sep 9, 2022

Thanks for your feedback. I wonder if this kind of feature shouldn't be more generic that just the R package. I believe this discussion could be related quarto-dev/quarto-cli#2372
You may want to contribute to the discussion there.

Probably quarto inspect or a variant should try to handle that. If it is not in the scope of the CLI, we can see what could be done at the R level after running quarto.

@wlandau
Copy link

wlandau commented Sep 9, 2022

Sure, sounds good. I opened quarto-dev/quarto-cli#2378 and referenced this thread.

@cderv
Copy link
Collaborator

cderv commented Jan 23, 2024

I opened an issue directly to track this more clearly in quarto-cli - this needs to be done there IMO

@cderv cderv closed this as not planned Won't fix, can't repro, duplicate, stale Jan 23, 2024
@cderv cderv added the upstream concerns an upstream library like quarto or pandoc label Jan 23, 2024
@wlandau
Copy link

wlandau commented Jan 23, 2024

Thank you, this would really help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request upstream concerns an upstream library like quarto or pandoc
Projects
None yet
Development

No branches or pull requests

3 participants