[gordonwoodhull]

The ask: a q2 branch on this repo

This PR can't merge to main (explained below) — but the change is ready and tested, so what we'd actually like is for you to carry it on a q2 branch here. We can't propose that directly: GitHub PRs need the target branch to exist, and only you can create it. The branch would be exactly this one commit; keeping it current is an occasional merge from main, and I'm happy to maintain it.

That gives Quarto 2 a stable, upstream-hosted target to bundle the engine from (we'd track the branch with git subtree, the same mechanism quarto-cli uses to vendor this repo), and early adopters a real path to Julia in Quarto 2 with no fork of record — while main stays clean and Q1-only until the schema change below ships.

What

Adds three static declarations to the engine's _extension.yml entry:

contributes:
  engines:
    - path: julia-engine.js
      name: julia
      claims:
        julia:
          kind: primary
          priority: 1
      file-extensions:
        - .jl

Quarto 2 resolves engines in two passes: pass 1 uses these declarations to resolve {julia} cells (and .jl files) to this engine without loading the engine module. Pass 1 is meant to be pure Rust — it shouldn't need to spawn anything as heavy as a Deno process just to ask "do you claim julia?", but without static declarations that's exactly what happens on every render:

• TS Engines which claim files will spawn Deno in Pass-1 quarto-dev/q2#576

The values mirror what the engine already answers dynamically, and these exact declarations have been exercised for months in Quarto 2's test suite, which carries a copy of this engine as a fixture (quarto-dev/q2#655).

Why it can't merge to main today

Quarto 1's external-engine schema is closed (src/resources/schema/definitions.yml: only path is allowed), so these keys are hard-rejected at extension load — verified against this branch with a quarto-cli dev build: YAML Validation Failed ... property name "name" is invalid. This PR's CI will fail the same way; that failure is the demonstration of the blocker.

The path to main:

1. A quarto-cli PR loosens the external-engine schema to accept-and-ignore these keys — explicitly not new Quarto 1 behavior: if Quarto 1 ever honored claims:, it would flip its deliberate jupyter-over-julia default. I'll file that PR and link it here.
2. That ships in a stable Quarto 1 release.
3. This merges to main with quarto-required bumped to that release, so older Quarto 1 gets a clean "please upgrade" at install instead of schema errors.

Semantics notes

• file-extensions is not a transcription of validExtensions(). That's empty here — correct in Quarto 1, where it's a global admission gate jupyter's .jl entry already passes. In Quarto 2 it's a per-engine declaration, so .jl must be listed or the engine is never asked about .jl files.
• claims-files is deliberately omitted: claimsFile is a percent-script content sniff and Quarto 2's static content-pattern claims aren't implemented yet, so .jl input still loads the engine. The zero-load win here covers {julia} cells in .qmd files.
• Quarto 2's static lookup is currently case-sensitive where dynamic claiming isn't ({Julia}) — a bug on our side, being fixed independently; nothing needed from you.

[gordonwoodhull]

The Quarto 1 forward-compat schema change this PR depends on is now filed: quarto-dev/quarto-cli#14936 (accepts and ignores name, claims, file-extensions, claims-files in the external-engine schema — no Quarto 1 behavior change).

[gordonwoodhull]

You know, this is more complicated than just using my fork of this repo as the upstream until Quarto 1 allows the Quarto 2 _extension.yml configuration syntax.

I'll close this and open a PR at that time.