Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to reorder engine prioritization with engines key in _quarto.yml #11807

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

jkrumbiegel
Copy link
Contributor

@jkrumbiegel jkrumbiegel commented Jan 7, 2025

Description

This PR adds the ability to change the order in which quarto checks if a markdown file or a language is claimed by an engine. This is necessary to allow users of the native julia engine to use it project-wide, without having to specify engine: julia in each notebook's frontmatter. This is because for backwards compatibility, the native julia engine neither claimed jl script files nor julia language blocks in qmd files, so that jupyter would continue to claim them as usual.

Now, the julia engine does claim these properties, however, jupyter also does, and because the engines are checked in order, jupyter will always win by default. However, by specifying engines: ['julia'] in _quarto.yml, the native julia engine is checked first and therefore wins.

This PR therefore fixes #10034 and #11305

Todos

I'm marking this WIP as I haven't added any tests, yet. First, I'd need to know that this approach is valid, for example if the location of the key in the config is correct. If it is, maybe some quarto-internal schema needs to be extended with this key as well, I couldn't quite make sense of that code when I tried to add engines below the project key at first. The top-level doesn't seem to get validated so I implemented the feature there.

Checklist

I have (if applicable):

  • filed a contributor agreement.
  • referenced the GitHub issue this PR closes
  • updated the appropriate changelog in the PR
  • ensured the present test suite passes
  • added new tests
  • created a separate documentation PR in Quarto's website repo and linked it to this PR

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
@cscheid
Copy link
Collaborator

cscheid commented Jan 7, 2025

Hey, this is going to be an excellent addition to Quarto, thanks!

I'm marking this WIP as I haven't added any tests, yet.

Sounds good, but this is something we'll definitely need tests for.

First, I'd need to know that this approach is valid, for example if the location of the key in the config is correct.

If it is, maybe some quarto-internal schema needs to be extended with this key as well, I couldn't quite make sense of that code when I tried to add engines below the project key at first.

Did you try adding it to src/resources/schema/project.yml. That should have worked. Specifically, I'd have added a top-level entry to the file like so:

- name: engines
  schema:
    arrayOf: string
  description: "..."

@jkrumbiegel jkrumbiegel marked this pull request as ready for review January 8, 2025 12:15
@jkrumbiegel
Copy link
Contributor Author

jkrumbiegel commented Jan 8, 2025

@cscheid I have added tests. I also added an entry to the schema yml file you suggested, although I can't tell if it had an effect on anything. I was already allowed to put the engines key at top level before, so nothing I can observe changed.

From my side this PR is good to go otherwise.

@jkrumbiegel
Copy link
Contributor Author

Small bump :)

@cderv cderv requested a review from cscheid January 14, 2025 14:00
@mcanouil
Copy link
Collaborator

mcanouil commented Jan 18, 2025

Am I mistaken to think this will also fix?

Side note: what about _metadata.yml?

@jkrumbiegel
Copy link
Contributor Author

Am I mistaken to think this will also fix?

It will not directly fix #3157, it does nothing to change the behavior of the engine key in _quarto.yml. But the idea was that this might not be the right fix anyway, because if you use multiple different languages in your project, it wouldn't make sense to set say julia as the engine for all of them. With the reordering, you'd ideally be able to prioritize all engines that matter to you if you use multiple languages.

Anything I can do to move this along @cscheid :) ?

@jkrumbiegel
Copy link
Contributor Author

One more bump :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Script files not picked up by julia engine
4 participants