Support for Deno Version 2

[detroyejr]

The Nixpkgs repository dropped support for Deno version 1 within the past week which means quarto is being built with version 2 (Bug report where this is discussed NixOS/nixpkgs#349444). Based on #10809 and #10773 it sounds like this isn't really a trivial version bump, but I wanted to put this on your radar and see if there's a timeline all the same.

If there's anything I can do to help move this along too, just let me know. Thanks!

[mcanouil]

Dependencies are updated, at most, once per release.

Edit: why did you open an issue if you saw that one was only tracking this?

---

Any bugs reported are the responsibility of the maintainers of the Nix build, which utilises incorrect dependencies and not solely Deno. The maintainers should clearly disclaim that the Nix Quarto package is not official, and any bugs should be reported to them first or replicated in an officially supported environment. Furthermore, they should disclaim that it is a custom build and may not be reliable.

To be clear, providing such wrong build is damaging especially without warnings to users.

https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/quarto/default.nix

[cscheid]

maybe someone would even say "damaging"

Please don't make accusations of this sort, or implications in this way. That's not behavior we consider acceptable in this forum. @mcanouil was stating facts.

I'm not going to respond to this full message, but I will tell you that I literally (as in actually 3 minutes ago) just came off of a 45-minute zoom conversation with two lead folks in the Deno project. Your message appears to imply that either Quarto or Deno are unwilling to work with one another, which is inaccurate. We have deep technical reasons to be unable to move to Deno 2, specifically around the removal of deno vendor and deno bundle. We are working on it. But this takes time.

Your message however, is not only unhelpful but also deeply ironic.

Two responses. First: The decision to remove Deno 1 from NixOS is not ours to make. And we simply cannot control the fact that Deno 2 doesn't offer tools we need, and we can't ship Quarto with Deno 2.

Second: The Quarto package in NixOS isn't going to work if Deno 1 is not available, and there's nothing we can do about it.
We can't control what other folks will choose to do, but we would prefer that packages are only offered if they are of a quality comparable to that of our distributions. @mcanouil was stating a fact: That's patently not the case for NixOS, and that's a problem.

Can we expect the quarto team to add a disclaimer that you will be relying upon an unsupported, unmaintained, and (as time goes on) potentially insecure version of deno?

These kinds of questions are unacceptable here. The framing of your question is such that both a "yes" or a "no" answer is inaccurate. We fundamentally disagree that Deno 1.46.x is unsupported. Your own screenshot from Bartek (who, by the way, was one of the people in the meeting I mentioned above) claims they "don't have plans to support 1.46.x for much longer". That's not a claim of no maintenance, and I really am asking you, once again, to be more careful in the future about these kinds of statements in our forums.

[06kellyjac]

Please don't make accusations of this sort, or implications in this way. That's not behavior we consider acceptable in this forum. @mcanouil was stating facts.

I'm quoting @mcanouil in a like-for-like situation specifically to show it's inappropriate.
Personally I would never call good-faith best efforts of Open Source contributors damaging and is exactly why I drafted up the response.

---

We have deep technical reasons to be unable to move to Deno 2, specifically around the removal of deno vendor and deno bundle. We are working on it. But this takes time.

My first line explicitly praises how useful this context you provided was.

---

Your message appears to imply that either Quarto or Deno are unwilling to work with one another, which is inaccurate.

My message says literally the opposite and outlines how there is a positive working relationship between quarto and deno.
One which focuses on getting things fixed for users rather than arguing over who's issue tracker a ticket should live in.

Our nixpkgs maintainers have been trying to fix the problem we have in our repository and I did not appreciate the negative attitude and the demand for disclaimers (which already exist) or allegations of damage.

The maintainers of the quarto package within nixpkgs were not immediately aware of the issues on nixpkgs-unstable and are practically bending over backwards to fix the problem we have on our end.

If we were, on purpose, shipping quarto with deno 2 then I could understand. But this is not an intentional action by those maintainers, or myself. I believe the nixpkgs maintainers who have raised issues and reached out here have demonstrated their desire to fix things and that response above was uncalled for IMO.

---

We fundamentally disagree that Deno 1.46.x is unsupported.

Great. If you have information we don't about the support plans for deno 1 we will happily add it back to the main nixpkgs tree.

With a more full context screenshot, this is all we had to go off in making our decision to drop deno 1 and I hope you can understand why we chose to do so:

I can understand if you're not comfortable making support statements on behalf of the deno project here.
If they could be made somewhere publicly visible though that'd help not just nixpkgs and 3rd party repositories but also other projects and users who still use deno 1 make informed plans around migration.
Otherwise I can take a DM via that discord account above or an email etc.

[mcanouil]

I will only say this: I meant damaging to the users. The unstable NixOS packaged version of Quarto expose Quarto users to issues they should never have faced in the first place and they Quarto team cannot fixed with its limited time and manpower.

It's totally different regarding Quarto using an old version of Deno because the Deno version is embedded inside Quarto in supported distributions.

If users using Quarto report to other repositories, there is not much that can be done except what @cscheid is already doing by catching errors to expose a message saying "it's likely a Quarto bug".
I don't understand why a user would prefer reporting elsewhere when using Quarto.

[06kellyjac]

In an attempt to wipe the slate clean:

Firstly I'd like to apologize for the recent issues with quarto and nixpkgs.
As the maintainer of the deno package in nixpkgs I shoulder the blame for in dropping deno v1 too quickly and not thoroughly checking in on dependent packages.
With the additional context in the screenshot above I hope you can understand both my original plans for a smooth migration and why we dropped v1 entirely in the end.

Secondly I'd like to apologize for my initial response here. I wrote it with the intention of rebuking a comment I disagreed with and defending the work of other nixpkgs maintainers, but at the end of the day I don't think it achieved much.

---

As I said above I welcome further context as to deno v1's support/maintenance/EoL plans
And I also hope that you can work with @detroyejr and other users of quarto via nixpkgs to reach a working solution.

---

The currently in-progress PR is looking to move to a pre-release but we generally don't do that, and when we do we usually add a suffix like Latest or something.
(This is just the latest iteration in an attempt to find a good solution for everyone, the previous change on this PR was to bring back deno 1 just for our quarto package)
It seems to work with deno 2 to some degree when running quarto check but if that's not intentional we'll avoid that.

To be clear the usage of deno 2 is via QUARTO_DENO, quarto isn't built from source in nixpkgs at the moment.

Although if we can add deno 1 back to nixpkgs and just use 1.5.57 properly then this doesn't matter

[mcanouil]

To be clear the usage of deno 2 is via QUARTO_DENO, quarto isn't built from source in nixpkgs at the moment.

To clarify, the Quarto NixOS package issue is unrelated to Deno itself. The package in question is user-contributed and unfortunately remains broken and unstable due to its construction, and it likely will continue to be so for the reasons mentioned.

If Quarto via NixOS packages appears to "work" on NixOS, it is purely by chance and is only intermittent. Therefore, it’s important to note that this situation has nothing to do with how Quarto uses Deno. Quarto does not disrupt Deno or require anything from it on NixOS, as Quarto is not supported on this distribution.
It is currently using and embedding an older version while migrating.

The disclaimer is to inform Quarto NixOS users that they are using something fundamentally broken and not officially supported. It’s not intended to avoid reporting issues about NixOS but to ensure that the user experience aligns with the Quarto Team’s intentions.

Even if Deno 1 were to remain in the NixOS packages (which is unlikely, as noted below), it would not resolve the issues with the Quarto NixOS package. This is because the dependencies are not pinned, resulting in incorrect Deno version, Pandoc version, among other issues.

Although if we can add deno 1 back to nixpkgs and just use 1.5.57 properly then this doesn't matter

I would recommend reading the GitHub issue linked in the original post.

• quarto cannot render NixOS/nixpkgs#349444

[detroyejr]

Thanks, your comment here and on the other issue thread was helpful.

The one issue was about a number of things and hard to find so I figured opening a focused one would be fine. I'll link next time.

[mcanouil]

Let's keep the discussion here.

[cscheid]

There's no timeline and the required changes will be very large. Deno 2 drops support for two tools that we fundamentally need in our packaging: deno vendor and deno bundle. Deno churn has been a constant source of toil in our repo and this will be the largest one yet. We hope to get it done at some point in 2025, but it's hope, not a promise.

[detroyejr]

Understood. Thanks for taking the time to respond to yet another deno issue.

[cscheid]

Yeah - we'd love to do it, but I don't want you to go down the rabbit hole only to realize much later that it's a huge task, and we can't justify the amount of resources required to support NixOS and other niche third-party packagers.