pure-Julia engine improvements

[cscheid]

Let's make #8645 even better:

• quarto check support for Julia engine #11503
• Schema support

[cscheid]

@jkrumbiegel Thinking about the conventions you've used for the YAML configuration, I wonder if we can improve them a bit to make them feel closer to the other quarto options. exeflags specifically feels a little off to me. Would you consider args instead? We use "arguments" instead of "flags" throughout the rest of codebase.

[jkrumbiegel]

We would have to change this in a breaking release in QuartoNotebookRunner which I think is fine, as its purpose is playing well with quarto. exeflags is what it's called in Julia's Distributed stdlib but args sounds good to me as well.

[cscheid]

exeflags is what it's called in Julia's Distributed stdlib but args sounds good to me as well.

Thanks for the info! This is sufficient evidence that a separate name makes sense in this context. I retract my request.

With the schema work I'm about to merge, there should be autocompletion and validation in tooling and rendering, so it's fine to keep as is.

Another schema question: the docs state that exeflags and env are the only fields used, but is the entire object made available to the code in some other way? I ask because we can configure our schema for the julia key to be "open" or "closed"; a closed schema would prevent typos in the keys, but might not be appropriate here.

[jkrumbiegel]

We have some undocumented settings that we're testing until they're ready, so from that point of view it's better if the schema is not closed.

[cscheid]

Got it, thanks.

When you do decide to document/support those settings, the options are declared here: https://github.com/quarto-dev/quarto-cli/pull/9319/files#diff-75a045d3e1fc8ac2f28df9cdfb1acec440a746abc7eb6ffc3cc9fd80064d2e09

After changing the files, recompile the schemas with quarto build-js (yes, terrible name) and make a PR with the generated files. We'll be happy to incorporate them.