Render to a new file name stores resources in directory with name of qmd file

[mikerspencer]

Bug description

When rendering a qmd file from the command line the resources folder is named after the qmd file, rather than the html output. This makes it impossible to parameterise output file names.

type	expected	actual
source	test.qmd	test.qmd
resources	test_1_files	test_files
output	test_1.html	test_1.html

Render from the command line (Ubuntu 20.04):

quarto render test.qmd --output test_1.html

---
title: "param test"
format: html
editor: source
params:
  x: 10
  y: 0.5
---

## Quarto

Quarto enables you to weave together content and executable code into a finished document. To learn more about Quarto see <https://quarto.org>.

## Running Code

* The param x is `r params$x`
* The param y is `r params$y`


```{r}
plot(rnorm(n = params$x,
           mean = params$y))
```

Checklist

• Please include a minimal, fully reproducible example in a single .qmd file? Please provide the whole file rather than the snippet you believe is causing the issue.
• Please format your issue so it is easier for us to read the bug report.
• Please document the RStudio IDE version you're running (if applicable), by providing the value displayed in the "About RStudio" main menu dialog?
• Please document the operating system you're running. If on Linux, please provide the specific distribution.

[astrowonk]

• 1 to this. I was thinking of trying to use quarto plus parameters to generate multiple .html files with different inputs to some python code (i.e. each page would have a different graph based on different data). I'll watch and wait for this to get closed.

[hathawayj]

+1 for this as well

[gavin-kelly-1]

My temporary workaround for this (obvious in retrospect, but posting here in case others like me don't spot it) is to copy the base script to desired-output-filename.qmd (e.g. contain the parameter values in it), run the render on that, and then remove spare copy of the qmd before looping onto the next parameter value. (Sorry about the duplicate issue 3703 - I did look but somehow missed this prior issue)

[dragonstyle]

Thanks for sharing the workaround (and no worries about the dupe I just stumbled across it just after I reviewed this!).

[gavin-kelly-1]

As a more medium-term workaround, I've set up a 'make'-based pre-processor so that my 'source' directory can get transformed into a staging area, which then gets rendered. This is a bit more general, as I have a file that stores an array of parameter settings that generate separate instances of the qmds - this initially felt a bit excessive, but I think is the natural way to build a project/website with many pages that reflect different parameter values applied to the same underlying document.

I've put a working, but not thoroughly tested, outline of how I do this at: https://github.com/FrancisCrickInstitute/babs-pre-quarto if it might be useful to others.

[cscheid]

Context for our next needs-discussion meet:

The problem

The fundamental problem we face with --output-dir and --output-file is that a large fraction of our tooling expects a correspondence between the input name and the output name. In addition, we don't fully control some of these outputs (such as the full set of files generated by a call to the LaTeX subsystem).

So, maybe the solution is to turn "input file names are sacrosanct" into a feature.

Make the workaround into a feature

@macroscian suggested a clever workaround here, which is to make a temporary copy of the input file under a new name, and render that file instead, eventually removing the "fake" .qmd file. This works surprisingly well, and I think it avoids most of the pitfalls.

Proposal

Interpret quarto render test.qmd --output test_1.html to mean:

• attempt to copy test.qmd to ${base_name(output-file)}.qmd, but refuse to proceed if that file exists.
• call the render functionality recursively on ${base_name(output-file)}.qmd
• delete ${base_name(output-file)}.qmd after the fact.

We then also interpret the "output-file" and "output-ext" yaml options similarly.

Limitations, related problems

We have a number of long-standing problems with output-dir, because it implicitly impacts how paths are resolved. This new implementation of output-file won't solve that problem. Until we solve the paths issue completely (and I don't know that we will be able to without radical changes to our execution semantics), we should still disallow output-file producing a directory different from the original source.

Milestone

This subsystem is very regression prone, so I'm proposing we start work on it for the 1.4 release.