bugfix: resolve engines before ignoreDirs

[gordonwoodhull]

The set of engines is no longer static / initialized at module load time.

Therefore resolveEngines() needs to be called before executionEngines(). ¹

This introduces tests for

• the ignoreDirs of knitr and jupyter engines, which were not being ignored, e.g. causing render of quarto-web to fail
• automatic inclusion of e.g.404.ipynb and 404.qmd files, which was succeeding but wasn't already tested
• promotion of e.g. index.ipynb and index.rmd files to section links in the sidebar. Engines were already resolved before this, but the feature was untested and it relies on the engine discovery interface, so here is a test.

Footnotes

1. Could there be a better design? There probably could, but resolveEngines() needs a project context and executionEngines() does not, so we can't just make the latter dependent on the former. ↩

[posit-snyk-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[cderv]

@gordonwoodhull I don't think this is the right place for this.

Regression fixes in 1.9 changelog are the bug fix we do in 1.9 AND also in 1.8 to fix a regression that we introduced in 1.8 compared to 1.9.

For regression between a 1.9 pre-release, and another, we don't add changelog. It is in a way expected that a 1.9 pre-release could brok. So this PR is part of the "New engine extensions" item you added a bit lower.

Hope it makes sense.

[gordonwoodhull]

Thanks @cderv, I was wondering as I did this. Felt weird not to log what the prerelease 1.9.14 will be about!

But I guess it's probably not helpful except for the very few people for whom 1.9.13 is breaking - and we haven't heard from any yet.

[cderv]

But I guess it's probably not helpful except for the very few people for whom 1.9.13 is breaking - and we haven't heard from any yet.

yes exactly. We don't have a good process for that.

I guess the right place would to mark this inside the 1.9.14 release note. Currently we only link users to the commit logs if you look at it: https://github.com/quarto-dev/quarto-cli/releases/tag/v1.9.13

We could find a new workflow logic to maybe add to this github release note some more information about what is noticeable in each pre-release. But this is a bit more work for us.

Unless we find an "automated way" by having specific keyword in commit, and looking for them to extract message for release not when we do create the github release 🤷‍♂️

Anyhow, our current logic is that there is no release note of specific changes for a specific prerelease (unless looking at commit themselves), and we advice all users to either use stable or very latest pre-release as it could be "normal" that a pre-release has breakage.
For no breakage => use stable. That is our logic I would say.

happy to evolve all this - to be discussed!