Single file rendering vs Project rendering: inconsistency in input path which is relative vs absolute

[cderv]

However, QUARTO_DOCUMENT_PATH does not output the same (using the absolute path for project and using a relative path for non-project)

I have looked into the difference between project render and singlefile render

Both start with render() which makes the input relative to Deno.cwd()

quarto-cli/src/command/render/cmd.ts

Lines 247 to 251 in a88e7cc

	renderResultInput = relative(Deno.cwd(), walk.path) || ".";
	if (renderResult) {
	renderResult.context.cleanup();
	}
	renderResult = await render(renderResultInput, {

However, when in a project, there will be some context compute which will end up normalizing (by adding back the Deno.cwd() like the following in renderProjects

quarto-cli/src/command/render/project.ts

Lines 287 to 294 in a88e7cc

	let projectRenderConfig = await computeProjectRenderConfig({
	context,
	projType,
	projOutputDir,
	projDir,
	options: pOptions,
	files: pFiles,
	});

quarto-cli/src/command/render/project.ts

Lines 150 to 168 in a88e7cc

	// file normaliation
	const normalizeFiles = (targetFiles: string[]) => {
	return targetFiles.map((file) => {
	const target = isAbsolute(file) ? file : join(Deno.cwd(), file);
	if (!existsSync(target)) {
	throw new Error("Render target does not exist: " + file);
	}
	return normalizePath(target);
	});
	};
	if (inputs.files) {
	if (alwaysExecuteFiles) {
	alwaysExecuteFiles = normalizeFiles(alwaysExecuteFiles);
	inputs.files = normalizeFiles(inputs.files);
	} else if (inputs.options.useFreezer) {
	inputs.files = normalizeFiles(inputs.files);
	}
	}

So basically,

• When this is a project, renderFiles is called with an absolute path
  

  quarto-cli/src/command/render/project.ts

  Lines 464 to 465 in a88e7cc

  	const fileResults = await renderFiles(
  	projectRenderConfig.filesToRender,

• When not inside a project, so singleFile render, renderFiles() is called with a relative path
  

  quarto-cli/src/command/render/render-shared.ts

  Lines 103 to 111 in a88e7cc

  	// otherwise it's just a file render
  	const result = await renderFiles(
  	[{ path }],
  	options,
  	nbContext,
  	undefined,
  	undefined,
  	context,
  	);

This is the different we see in those environment variable from this PR, as it will be inherited by target.source

quarto-cli/src/execute/environment.ts

Line 16 in a88e7cc

Deno.env.set("QUARTO_DOCUMENT_PATH", dirname(options.target.source));

It seems there is room for improvement to make things work the same.

Originally posted by @cderv in #12271 (comment)

[cderv]

I believe this will have an impact on our cache efficiency because the fileInformationCache will not be shared with the two modes

$ context.fileInformationCache
0 =
{"C:\Users\chris\Documents\DEV_R\quarto-cli\tests\docs\inspect\cleanup-issue-12336\cleanup-bug.qmd" => Object}
key =
'C:\\Users\\chris\\Documents\\DEV_R\\quarto-cli\\tests\\docs\\inspect\\cleanup-issue-12336\\cleanup-bug.qmd'
value =
{fullMarkdown: {…}, includeMap: Array(0)}
1 =
{"docs/inspect/cleanup-issue-12336/cleanup-bug.qmd" => Object}
key =
'docs/inspect/cleanup-issue-12336/cleanup-bug.qmd'
value =
{fullMarkdown: {…}, includeMap: Array(0), engine: {…}, target: {…}, metadata: {…}, …}
size =
2

the context store two file information which are for the same file, but key is either full path or relative path

I found this while looking at

• keep-ipynb does not keep notebook #12780

and how quarto inspect works to clean quarto_ipynb file. Inspect will call at the first document information but also project information

quarto-cli/src/inspect/inspect.ts

Lines 239 to 241 in e426fbc

	if (context?.config) {
	config.project = await inspectProjectConfig(context);
	}

And so I think it can't reuse the previously computed file information, because of that.

[cscheid]

I don't understand the specifics here, but I'm pretty certain that the key in the fileInformation cache should always be a fully resolved absolute path. If it's not, then it's a bug somewhere.

[cderv]

I can explain why live, but I filed the above in this specific issue because I believe it is the same bug that impacts fileInformationCache. Or at least highly related