Inconsistent Behavior Between R and Python when using .Qmd extension (capital Q).

[christian-million]

Bug description

When rendering a Quarto document that uses a .Qmd extension (as opposed to a .qmd extension), R code chunks render perfectly but python code chunks stop the document from rendering.

I would expect consistent behavior from both languages, whether it generates an error or successfully renders .Qmd documents.

Note: I had opened a StackOverflow thread describing my problem about 3 days ago. I just recently discovered the solution and have not yet updated that post with the solution. However, the post contains more information than this Bug Report is requesting.

Steps to reproduce

Using Python

File Name: example.Qmd

---
title: Example
subtitle: Example
format: html
---

```{python}
2 + 2
```

Using R

File Name: example.Qmd

---
title: Example
subtitle: Example
format: html
---

```{r}
2 + 2
```

Expected behavior

I would expect one of the following scenarios, depending upon the design decisions by Quarto Developers:

1. Both .Qmd documents generate a warning/error message about "File Extensions .Qmd are not allowed"
2. Both .Qmd documents successfully render the documents with/without warning about supported file extension.

Actual behavior

When the .Qmd document is rendered and contains R code chunks, the document renders successfully.

When the .Qmd document is rendered and contains Python code chunks, I receive the following error:

C:\Users\chris>quarto render Desktop\example.Qmd
ERROR: Unable to render Desktop\example.Qmd

Stack trace:
    at fileExecutionEngineAndTarget (file:///C:/Program%20Files/Quarto/bin/quarto.js:41260:15)
    at async renderFileInternal (file:///C:/Program%20Files/Quarto/bin/quarto.js:77115:36)
    at async renderFiles (file:///C:/Program%20Files/Quarto/bin/quarto.js:77062:17)
    at async render (file:///C:/Program%20Files/Quarto/bin/quarto.js:81807:21)
    at async Command.fn (file:///C:/Program%20Files/Quarto/bin/quarto.js:81954:32)
    at async Command.execute (file:///C:/Program%20Files/Quarto/bin/quarto.js:8104:13)
    at async quarto (file:///C:/Program%20Files/Quarto/bin/quarto.js:114968:5)
    at async file:///C:/Program%20Files/Quarto/bin/quarto.js:114986:9

Changing the .Qmd to .qmd allows both documents to run successfully:

C:\Users\chris>quarto render Desktop\example.qmd

Starting python3 kernel...Done

Executing 'example.ipynb'
  Cell 1/1: ''...Done

pandoc
  to: html
  output-file: example.html
  standalone: true
  section-divs: true
  html-math-method: mathjax
  wrap: none
  default-image-extension: png

metadata
  document-css: false
  link-citations: true
  date-format: long
  lang: en
  title: Example
  subtitle: Example

Output created: example.html

Your environment

• Microsoft Windows 11 Home Version 10.0.22621 Build 22621
• CLI
• RStudio Desktop 2023.12.0 Build 369

Quarto check output

C:\Users\chris>quarto check
Quarto 1.4.547
[>] Checking versions of quarto binary dependencies...
      Pandoc version 3.1.11: OK
      Dart Sass version 1.69.5: OK
      Deno version 1.37.2: OK
[>] Checking versions of quarto dependencies......OK
[>] Checking Quarto installation......OK
      Version: 1.4.547
      Path: C:\Program Files\Quarto\bin
      CodePage: 1252

[>] Checking tools....................OK
      TinyTeX: (not installed)
      Chromium: (not installed)

[>] Checking LaTeX....................OK
      Tex:  (not detected)

[>] Checking basic markdown render....OK

[>] Checking Python 3 installation....OK
      Version: 3.12.1
      Path: C:/Program Files/Python312/python.exe
      Jupyter: 5.7.1
      Kernels: python3

[>] Checking Jupyter engine render....OK

[>] Checking R installation...........OK
      Version: 4.3.0
      Path: C:/PROGRA~1/R/R-43~1.0
      LibPaths:
        - C:/CDM/R/Library
        - C:/Users/chris/AppData/Local/R/win-library/4.3
        - C:/Program Files/R/R-4.3.0/library
      knitr: 1.45
      rmarkdown: 2.25

[>] Checking Knitr engine render......OK

[cderv]

We do have this check for Jupyter engine

quarto-cli/src/execute/jupyter/jupyter.ts

Lines 184 to 185 in f2ee879

	// if this is a text markdown file then create a notebook for use as the execution target
	if (isQmdFile(file) || isPercentScript) {

and only .qmd is supported - lowercase important

quarto-cli/src/execute/qmd.ts

Lines 10 to 13 in f2ee879

	export function isQmdFile(file: string) {
	const ext = extname(file);
	return kQmdExtensions.includes(ext);
	}

quarto-cli/src/execute/types.ts

Line 19 in f2ee879

export const kQmdExtensions = [".qmd"];

We don't have such check for knitr engine.

I don't know if we should support .Qmd. I believe the right fix could be

• Make document with engine: knitr fails
• Improve the error message to explain why it is unable to render (wrong extension)

Though, this could be breaking change for current R users having .Qmd files.

Easy fix would be supporting .Qmd in jupyter engine too, by making the comparison of extension case-insentive

@dragonstyle @cscheid what are you thoughts on this

[christian-million]

In case it helps, I have no business case for using the .Qmd extension. I had created the file with capitalization out of habit from using .Rmd documents in the past. I no longer intend to use the capital .Qmd extension, however, in light of this.

[cscheid]

I think we should disallow it. The complication is that the handling of capitalization across file systems is pretty tricky. Linux is case-sensitive, but Windows and macOS are case-preserving, unless you create a file-system that is case-insensitive by design, which is possible but rare.

So it might not be very easy to disallow capitalization robustly.

EDIT: I take it back. Our code already takes the lowercase of some extensions, but not all. We should be consistent. It's an easy fix.

[cscheid]

Following up on this;

The error I get on main is slightly different:

ERROR: Can't determine execution target for test.Qmd

Like @cderv mentioned, the issue is that the Jupyter engine is expecting a .qmd or a "percent script" in order to create an execution target. More fundamentally, engines provide their own implementation code for determining execution targets, and so we can't provide an error message that is both: 1) uniform across engines and 2) specific about the cause of the problem.

With that said I think this specific bug has a simpler cause. In engine.ts:fileExecutionEngine, we take the lowercase of the extension to determine if the file can be handled, but we are not consistent about the treatment.