Please release only Quarto files, and no dependencies.

[yurivict]

Dependency files are included in tarballs: Deno, pandoc, sass. etc.

Release tarballs should contain only Quarto files, otherwise there would be conflicts with pre-installed Deno, pandoc, etc.

[yurivict]

Additionally, quarto files in https://github.com/quarto-dev/quarto-cli/releases/download/v0.9.30/quarto-0.9.30-linux-amd64.tar.gz should be in share/quarto, not in share/.

[jjallaire]

We understand that you are attempting to package quarto and therefore want the binaries/resources to behave a bit differently than we have them. Note though that as currently developed and released Quarto is not a good fit for packaging with externalized dependencies. This is mostly because of fragile bleeding-edge dependencies (as we discussed before the Deno dependency can sometimes need to be months old and sometimes a commit from yesterday depending on where we are with development). The same can be true for Pandoc -- Pandoc frequently has breaking changes across releases and we therefore need to make sure our code aligns with an exact version of Pandoc. Similar issues have occurred in the past with esbuild.

So the idea of releasing a Quarto binary that doesn't embed dependencies will in many cases result in a broken installation for users, so we don't make this option available. If you want to package Quarto with dependencies externalized
you can go ahead and try, but my guess is that it will be very difficult to make it work consistently over time. Other package systems (e.g. homebrew / scoop / etc.). have taken the approach of bundling our entire release (embedded dependencies). We are basically like a Ubuntu Snap. I realize that my saying this could result this thread becoming a mini re-litigation of the whole Snap/Flatpack debate about embedded vs. external dependencies. I'd rather not do that -- we've made our choice for what we think our sound technical reasons (mostly being able to control the versions of other fast-moving projects that often break backwards compatibility). Its certainly possible in the future when our development and the development of those projects stabilizes a bit that we can more reliably have external dependencies, but we definitely aren't there today.

[yurivict]

I am trying to create a FreeBSD port for Quarto. But ports can't use downloaded pre-built binaries. And the binaries are only for Linux. So I am not sure what can be done here.

[jjallaire]

I am not sure if this will work right now unless FreeBSD has a system like Snap/Flatpack to allow for embedded dependencies. If there are FreeBSD binaries for deno, pandoc, esbuild, and dart-sass available that happen to match our current versions well enough then you could just maintain a fork of our repo that doesn't embed dependencies. However, my guess is that users will end up stuck on very old versions of Quarto b/c if the FreeBSD repos aren't moving in unison with our dependencies you won't be able to update Quarto.

A better approach to getting things working on FreeBSD is to create a version of Quarto with the dependencies embedded and then make that archive available to users. The FreeBSD core repos might not allow this but some sort of sidecar distribution would (I don't know FreeBSD well enough to say whether/if/how this is possible though).

[fanninpm]

@yurivict Is this because of RStudio? If that's the case, I would recommend pinning RStudio's version to v2021.09.2+382 until the situation improves. In the interim, you can encourage your users to use an alternative IDE, such as VSCode.

[yurivict]

The RStudio port is already updated to 2022.02.0+443.

I think that Quarto shouldn't be added as RStudio dependency until Quarto is ready to be properly packaged and used. Adding immature dependencies like that only wastes time of those who maintain RStudio ports.

[jjallaire]

There is a build flag you can set that excludes Quarto entirely from the build and product (we use that for Arm builds and RHEL 7 builds)

[jjallaire]

See https://github.com/rstudio/rstudio/blob/a35edfc361df5b9e23af3598df25453aa8d229e6/CMakeGlobals.txt#L231 for the flag/usage