Quarto 1.8 - potential short-term instability in the next couple of weeks

[cscheid]

Hello!

As the technical lead in the quarto-cli project, I wanted to give you a heads up about some upcoming changes in the code base.

You might be aware that quarto-cli is at its core a Typescript project running on Deno. It's a great fit for our purposes, but we're lagging behind in updating Deno 1 to Deno 2 for a number of reasons. These mostly have to do with quirks of our existing code base and features that were removed in the Deno 1 to Deno 2 migration (notably, deno bundle and deno vendor)

We have a few PRs ready to merge that should get us to the latest Deno 2 release, but we believe there might be some turbulence (for example, with installers) that we haven't quite sorted out yet.

We expect this work to take around two weeks, during which time we recommend you to hold back on Quarto 1.8 upgrades. Quarto 1.8 is the prerelease version we've started to work on just over a week ago, and so you will be missing no new features. When we're back to our usual steady state, we will make another announcement here.

If you need the very last 1.8 prerelease before the Deno 2 migration, use 1.8.2.

Thank you so much, as always, for using Quarto, and let us know if you have any questions in the comments here!

[ntluong95]

Thank you for the information. But where I can see find the Quarto 1.8 roadmap?

[cscheid]

We don't share roadmaps in this project.

[cbrnr]

This is great news! Does this mean that quarto-cli will be easier to package because it will run with the latest deno versions? Typically, Linux distributions (but also Homebrew on macOS) only ship the latest Deno versions for other apps to depend upon.

[cbrnr]

Arch packages can run tests in the check() function, and I agree this would be a good idea here.

[cderv]

Does this mean that quarto-cli will be easier to package because it will run with the latest deno versions? T

@cbrnr 1.8 will use Deno 2, and we won't be stuck anymore with newer Deno. So yes we'll be able to update to future Deno 2 version.

In order to package it for a Linux distribution, I would want to use other system packages as dependencies.

However, as explained by Mickaël, we'll still bundle a specific deno version that is meant to be used with Quarto.

Using a different version and rebuilding Quarto with it could still have side effects and unsupported problem - that will only be dealt with at next Deno version update for a future Quarto version.

Hope it is clear.

[cbrnr]

Thanks @mcanouil and @cderv! I totally understand that you can only support the official builds, and any errors found with custom builds are the packagers' responsibilities. However, as it has been rather difficult to build Quarto in the past - mainly due to exact version pins of dependencies - I'm very happy that this process will be easier if Quarto works (at least in principle, e.g., by not using any deprecated/removed things) with the latest Deno versions (I hope I understood you correctly)! I'm also asking because it would be great if Quarto was available as a core Arch package (in extras) as opposed to the AUR, which apparently has been discussed at some point. Currently, the Arch package seems to be broken, but once 1.8 lands and is stable, I think it would be worth a try to revive it.

[cscheid]

I'm very happy that this process will be easier if Quarto works (at least in principle, e.g., by not using any deprecated/removed things) with the latest Deno versions (I hope I understood you correctly)! I'm also asking because it would be great if Quarto was available as a core Arch package (in extras) as opposed to the AUR, which apparently has been discussed at some point. Currently, the Arch package seems to be broken, but once 1.8 lands and is stable, I think it would be worth a try to revive it.

We certainly hope that it will be easier to package, but as project lead, let me temper expectations a little bit. We're only three full-time devs working on quarto-cli, and we need to be strategic about our decisions.

We believe that people enjoy using Quarto in part because of how hard we work to keep our distributions stable and how hard we try to keep backwards compatibility. We love Pandoc, Deno, and Typst, but these are three packages that have different perspectives, and do break backwards compatibility much more aggressively than we do. That means that Quarto needs to be very careful about specific versions. The maintenance burden of ensuring Quarto continues to work whenever an upstream updates is just too much for us.

We understand that people also love Arch and nixos. But this means we depend on the invested Quarto subcommunities in those spaces to be shepherds of the specific distributions, and will continue to do so for the foreseeable future.

[cbrnr]

Oh yeah, makes total sense! I'm trying to engage with both Quarto and Arch, because I care a lot about the two projects/communities and would like to make Quarto as easily installable on Arch as possible (and this means trying to get it into one of the core repositories).