keep-ipynb does not keep notebook

[cderv]

---
format: html
keep-ipynb: true
---

```{python}
1 + 1
```

Simple example where the intermediate .ipynb is not kept.

❯ quartoPreRelease check
Quarto 1.8.4
[>] Checking environment information...
      Quarto cache location: C:\Users\chris\AppData\Local\quarto
[>] Checking versions of quarto binary dependencies...
      Pandoc version 3.6.3: OK
      Dart Sass version 1.87.0: OK
      Deno version 2.3.1: OK
      Typst version 0.13.0: OK
[>] Checking versions of quarto dependencies......OK
[>] Checking Quarto installation......OK
      Version: 1.8.4
      Path: C:\Users\chris\scoop\apps\quarto-prerelease\current\bin
      CodePage: 1252

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

[>] Checking LaTeX....................OK
      Using: TinyTex
      Path: C:\Users\chris\AppData\Roaming\TinyTeX\bin\windows\
      Version: 2025

[>] Checking Chrome Headless....................OK
      Using: Chrome found on system
      Path: C:\Program Files\Google\Chrome\Application\chrome.exe
      Source: Windows Registry

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

[>] Checking Python 3 installation....(None)

      Unable to locate an installed version of Python 3.
      Install Python 3 from https://www.python.org/downloads/

[>] Checking R installation...........OK
      Version: 4.5.0
      Path: C:/PROGRA~1/R/R-45~1.0
      LibPaths:
        - C:/Users/chris/AppData/Local/R/win-library/4.5
        - C:/Program Files/R/R-4.5.0/library
      knitr: 1.50
      rmarkdown: 2.29

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

[cderv]

This is a regression. I don't see the problem with v1.6.43.

[cscheid]

This is a regression. I don't see the problem with v1.6.43.

I think it's a regression caused by us attempting to fix those "temporary cleanup" calls.

[cderv]

I have searched for the root cause to be sure we fix this correctly. This is the faulty commit a6c6d5c merge of PR

• Clean up transients from quarto inspect #12337

This needs to be aware of keep-ipynb probably

quarto-cli/src/project/project-shared.ts

Lines 636 to 647 in e426fbc

	export function cleanupFileInformationCache(project: ProjectContext) {
	project.fileInformationCache.forEach((entry) => {
	if (entry?.target?.data) {
	const data = entry.target.data as {
	transient?: boolean;
	};
	if (data.transient && entry.target?.input) {
	safeRemoveSync(entry.target?.input);
	}
	}
	});
	}

Currently notebook is supposed to be cleaned (or not) in

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

Lines 716 to 724 in e426fbc

	function cleanupNotebook(target: ExecutionTarget, format: Format) {
	// remove transient notebook if appropriate
	const data = target.data as JupyterTargetData;
	if (data.transient) {
	if (!format.execute[kKeepIpynb]) {
	removeIfExists(target.input);
	}
	}
	}

inside the execute logic of the jupyter engine

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

Lines 437 to 439 in e426fbc

	// if it's a transient notebook then remove it
	// (unless keep-ipynb was specified)
	cleanupNotebook(options.target, options.format);

So we could teach cleanInformationCache() about keep-ipynb but we would still have two places of cleanup... 🤔 So maybe we can regroup and do once.

[cderv]

So we could teach cleanInformationCache() about keep-ipynb but we would still have two places of cleanup... 🤔 So maybe we can regroup and do once.

Note that easy - keep-ipynb information is not available everywhere. It feels like the cached information should be used more, especially during execution, so that keep-ipynb: true could make transient: true become transient: false

[cderv]

But this is not really easy... this fileInformationCache is not that simple to handle.
I acknowledge I don't understand some of the changes for the fileInformationCache and its cleanup. I would have thought engine.executeTargetSkipped() would have cleaned up the quarto_ipynb. So I want to try a few things, but I'm happy to have insights or ideas too.

I have currently a fix that require to update the cached information from within engine.execute and it feels not right.

[cscheid]

(And now you start to see why the execution planner is hard! :) )