Allow using a custom env for loading QuartoNotebookRunner

[jkrumbiegel]

Description

This PR adds an environment variable QUARTO_JULIA_PROJECT with which one can load QuartoNotebookRunner from a different environment than the one handled by quarto itself.

This is primarily intended for development purposes or custom setups where a different version of QuartoNotebookRunner than the one specified in the internal Project.toml should be used.

I noticed while adding this that quarto tried to load a very old version of QuartoNotebookRunner from my global env when I specified an empty project. So I've additionally removed the global env from the load path for the relevant julia processes, because we never intend to load anything from there. It's either the custom env or the quarto-handled env.

Checklist

I have (if applicable):

• filed a contributor agreement.
• referenced the GitHub issue this PR closes
• updated the appropriate changelog

[cscheid]

Thanks for the PR.

Will this cause confusion with users that have JULIA_LOAD_PATH in their environment to a value different from @:@stdlib? (I'm not a Julia user, just trying to understand the consequences here)

[jkrumbiegel]

The values I changed only apply to the process that loads QuartoNotebookRunner. I'm basically just making sure that this package is not by accident loaded from somewhere else than the custom project (where it might not be installed correctly) or our internal project (where it is installed correctly as ensured by our code).

The load path modification does not apply to the workers, their behavior is similar to what users would get in a normal julia session. Although arguably, for reproducible notebooks, even there it would be better to have a narrower load path I guess, but that's not in scope here.

[jkrumbiegel]

Test failures seem unrelated

[cscheid]

Test failures seem unrelated

They are related to julia-native, though. That makes me a bit suspicious. The failures are all on Windows and in the julia-native engine tests, and they also don't happen in the CI runs on main.

Do you have a Windows machine that you've checked locally?

[jkrumbiegel]

When I wrote that comment none of the tests failing were julia, don't know why that changed in the second invocation after merging in master again. Maybe something changed in the test framework?

[cscheid]

When I wrote that comment none of the tests failing were julia,

I don't think that's accurate. This is one of the errors for the run on b14385b: https://github.com/quarto-dev/quarto-cli/actions/runs/8685356621/job/23814673505 It's failing on quarto render docs\markdown\commonmark-julianative.qmd --to commonmark

[jkrumbiegel]

You're right, I missed that for other unrelated failures on ubuntu. There was indeed a small (one character) windows issue which is fixed now.

[jkrumbiegel]

Thanks, and just a reminder @cscheid that there's a docs PR at quarto-dev/quarto-web#1078