Quarto in docker aarch64

[vnijs]

@dpastoor Thanks for working on making quarto available on arm chips (https://github.com/quarto-dev/quarto-cli/pull/237)

Quarto is a great new tool and I'd love to provide access to my students through docker. Works fine on AMD processors but more and more of my students have M1 macs. I found that using the arm build here https://github.com/LukeChannings/deno-arm64 and adding the below to the configure-linux.sh files gets the deno build process started and rolling for a bit. However, it chokes on deno_dom. Any chance you could provide some suggestions on next steps?

ERROR: The architecture aarch64 is missing the dependency deno_dom

DENOURL=https://github.com/LukeChannings/deno-arm64/releases/download
DENOFILE=deno-linux-arm64.zip

https://github.com/quarto-dev/quarto-cli/blob/main/configure-linux.sh

[dpastoor]

Hi @vnijs

This is a little complicated as its not just about deno, its about some of the other dependencies such as pandoc, dart, esbuild, etc.

We ended up pausing this to wait for the build status of the broader ecosystem to improve around ARM support. I do think this is becoming more and more relevant (and indeed at RStudio ourselves we feel this as many people are getting on m1's).

Out of curiosity, what part of the docker containers are you looking to take advantage of for the students? We've found that the mac ecosystem is generally reasonable for people to get a working environment in without any containerization, and you can happily use the mac quarto installer without any noticeable performance issues. That might be a reasonable way to bridge the cap, and we could keep this issue open and have you test for when we cycle back to giving those builds another shot, hopefully in the next couple months.

[jjallaire]

One other note: Deno DOM isn't strictly required (as there is a fallback to a WASM version for unsupported architectures). I don't think our configure scripts currently reflect this, but just wanted to note that the fallback is possible.

[vnijs]

@dpastoor We use a lot of different tools and packages in our program and docker is a good way to ensure all students, TAs, and instructors have the same versions of all tools and packages. Everything works and works the same on windows, mac, or on our linux server.

I'm not familiar with dart and esbuild but pandoc seems to work fine on aarch64. That is, I can create PDFs and HTML files using rmarkdown and pandoc just fine.

[eitsupi]

I think this issue is a duplicate of #190.

Docker Desktop on Mac can use linux/amd64 Docker images, right?

[vnijs]

FYI Our experience with linux/amd64 docker images on M1 macs has been extremely poor. Even when it sometimes did run, performance was 10-15x slower.

[znmeb]

I'm looking at Quarto for both the Raspberry Pi and the NVIDIA Jetsons. I have two Raspberry Pi Compute Module 4s running the 64-bit PiOS and three Jetsons. I have no need for a 32-bit Quarto; too much other software doesn't run on 32-bit ARM Linux.

I just attempted to build deno from source on a Pi and it failed. After some digging into issues, I discovered this:

https://github.com/denoland/deno/issues/1846#issuecomment-888965232

I have Docker set up on my Jetsons so I'm going to see if I can make that work. I have no plans to run Docker on the Pis, though.

[vnijs]

Thanks for your comment @znmeb. Looks like the Deno team is making progress https://github.com/denoland/deno/issues/1846#issuecomment-1171742017, are linking to (unofficial) binaries, and publishing scripts to build binaries on arm64.

https://github.com/noxifoxi/deno_install-arm64

[vnijs]

The new Rstudio dailies for aarch64 seem to be working well! The last piece I'm missing is quarto. I've been able to skip past issues on architecture and deno_dom. However, I'm not sure how to get the dependencies scripts to find that pandoc is available and installed in /opt/conda/bin/pandoc. Any suggestions?

[jjallaire]

We just merged a bunch of changes to be able to produce a conda-forge version of quarto (this will go live w/ v1.1). Part of this is that any of our binaries can now be provided externally. @msarahan (who did all of the conda work) should be able to help you sort this out.

[msarahan]

For the conda package to work (i.e. conda install quarto), we're missing aarch64 packages on a few things:

• https://github.com/conda-forge/dart-sass-feedstock/pull/7
• https://github.com/conda-forge/deno-feedstock/pull/11
• https://github.com/conda-forge/deno-dom-feedstock/

If you can help on any of those, it would be much appreciated. In the meantime, you can also manually set environment variables to redirect quarto to your own executables. These are in the conda recipe, but I will also find a place to put them in the quarto docs.

https://github.com/quarto-dev/quarto-cli/blob/main/package/conda-recipe/build.sh#L27-L32

  #!/bin/sh
  export QUARTO_DENO=$PREFIX/bin/deno
  export QUARTO_DENO_DOM=$DENO_DOM_PLUGIN
  export QUARTO_PANDOC=$PREFIX/bin/pandoc
  export QUARTO_ESBUILD=$PREFIX/bin/esbuild
  export QUARTO_DART_SASS=$PREFIX/bin/sass
  export QUARTO_SHARE_PATH=$PREFIX/share/quarto

[vnijs]

@msarahan Thanks for working on this! I looked at the links you shared but it wasn't obvious to me what parts exactly you could use help with.

[msarahan]

aarch64 on the deno feedstock is currently blocked by running out of memory on Travis CI - the PR is at https://github.com/conda-forge/deno-feedstock/pull/11 - if you have ideas or tips on how to reduce memory usage, that will help.

Deno-dom is blocked because it depends on deno. We can't get aarch64 builds of this until we have deno built.

dart-sass is done. Esbuild is done.

Pandoc seems to be available for aarch64. Right now, the pandoc packages are binary repacks. I think they work fine for aarch64, but you'll know better than me. They do not work for MacOS on aarch64, so it seems we have to get a haskell stack to build pandoc from source. There are some efforts there that seem to have stalled. I'm trying to figure out what the best way forward is. https://github.com/conda-forge/ghc-feedstock/pull/24. Right now, my challenge is that the binary repack of a bootstrap GHC installation takes forever on MacOS (conda-build's binary inspection features bog down with many files). Very slow iteration time. https://github.com/conda-forge/ghc-bootstrap-feedstock/pull/10

[znmeb]

Pandoc seems to be available for aarch64. Right now, the pandoc packages are binary repacks. I think they work fine for aarch64, but you'll know better than me. They do not work for MacOS on aarch64, so it seems we have to get a haskell stack to build pandoc from source. There are some efforts there that seem to have stalled. I'm trying to figure out what the best way forward is. conda-forge/ghc-feedstock#24. Right now, my challenge is that the binary repack of a bootstrap GHC installation takes forever on MacOS (conda-build's binary inspection features bog down with many files). Very slow iteration time. conda-forge/ghc-bootstrap-feedstock#10

I had a Docker Haskell stack to build Pandoc on my aarch64 Jetsons before the Pandoc team started shipping aarch64 Linux binaries. It was painfully slow on Bionic because you need to rebuild Haskell itself to get an up-to-date Pandoc. It was an overnight job even on an eight-core 16 GB Xavier NX; it's mostly single-threaded.

Does the Pandoc team have a project / funding to build binaries for MacOS? Does the Haskell team have a project / funding to build their stack? This shouldn't be on Quarto or conda-forge to get done.

[vnijs]

I have pandoc installed through conda on my M1. Works fine. There doesn't seem to be a separate binary for M1 and M2 at the link below so I assume that uses Rosetta

https://github.com/jgm/pandoc/releases/tag/2.19.2

[nathancarter]

Also eagerly awaiting the resolution of this one. Above the question of use case arose, since Macs provide a nice Unix layer anyway, so why not use the native Mac stuff? The use case is when creating a project on which many folks develop, one can add a Dockerfile to the project. VS Code makes this very nice so that whether you're on a Mac, PC, or GitHub Codespace, you have the exact same dev env everywhere. It is not possible to do that right now if the project involves Quarto, because one cannot put Quarto into a dev container in a way that plays nicely with anyone on an M1 Mac. Not complaining, of course. :) Just adding another use case, since it was asked.

[eitsupi]

This is just a note.

Currently quarto uses chromium for rendering diagrams into non-HTML formats, but there seems to be no way to binary install chromium in arm64 version of the Ubuntu Docker containers.

[nathancarter]

Right now one of the problems that flows from this is the following: One can open VS Code, ask it to create devcontainer files for a new project, choose your base container, then add the Quarto-CLI feature, and it will happily do so, take about 5 minutes to build you a container, then fail on the final step if you're on an ARM architecture, because of the Quarto-CLI feature. This is particularly unfortunate because the VS Code devcontainer Features list is designed to make it easy for those new to containerized development to add features easily, but it actually leads you down the garden path, takes your phone, hits you on the head, and leaves your unconscious body in the shrubbery. (Your choices are to re-run the build and fail again or open the devcontainer locally and, if you're in the new-to-containers target audience, wonder what choices in life led you to this end.)

Question 1: Is the correct place for me to report that bad surprise this repo?

Question 2: Is there a script anywhere that installs Quarto reliably in a devcontainer, independent of architecture, so I could just set that script as a final build step in my Dockerfile, in the meantime before the Quarto-CLI feature is ready for ARM use?

[eitsupi]

Question 1: Is the correct place for me to report that bad surprise this repo?

Did you read the README, which clearly states that arm64 is not supported? https://github.com/rocker-org/devcontainer-features/blob/main/src/quarto-cli/README.md#supported-platforms

[nathancarter]

Question 1: Is the correct place for me to report that bad surprise this repo?

Did you read the README, which clearly states that arm64 is not supported? https://github.com/rocker-org/devcontainer-features/blob/main/src/quarto-cli/README.md#supported-platforms

That's exactly my point. Here's the user experience, literally this:

Now if you hover over it and click the little information icon and then read the webpage it brings up, you'll see that one of the sections tells you that this feature isn't for you. But before you install every feature, do you click the info icon on them all and read the whole readme? The purpose of the features list is that it's supposed to be click and go, the opposite of digging into other people's repos.

To reiterate, the current situation is this: If you check that box, you bork your repo, but don't find out for 5 minutes, then have to figure out how to fix it, by digging into files that the very box was supposed to help you stay out of. The software shouldn't let you check a box that is 100% guaranteed to shaft you.

[jimjam-slam]

This is just a note.

Currently quarto uses chromium for rendering diagrams into non-HTML formats, but there seems to be no way to binary install chromium in arm64 version of the Ubuntu Docker containers.

This is a bit ancillary to the larger discussion about dev container features, but I think a chromium package was published for Ubuntu Jammy on am64 in October: https://launchpad.net/ubuntu/jammy/arm64/chromium-browser

EDIT: I beg your pardon, that's October last year:

This is a transitional dummy package. It can safely be removed. chromium-browser is now replaced by the chromium snap

[eitsupi]

@nathancarter Unfortunately, there is currently no way for Dev Container Features to notify users of the executable environment other than in the README. So you should vote for this issue. devcontainers/spec#58

Problems with the VSCode Dev Containers' UI can be reported here https://github.com/microsoft/vscode-remote-release

[nathancarter]

Good tip--I gave my thumbs up to that issue, because it seems to be exactly the core issue here, not anything wrong with Quarto specifically. Thank you!

[dragonstyle]

This should be supported now in Quarto 1.3 pre-release.

[vnijs]

@dragonstyle Nice? Are there install instructions for that so we can test it out?

[dragonstyle]

There are no special instructions currently (there is a .deb file or tarball available)- the downloads are available here:

https://quarto.org/docs/download/prerelease

For the tarball install, there are a set of instructions for the general x86 tarball that you can generally follow here (ignore the download button):

https://quarto.org/docs/download/tarball.html?version=1.2.335&idPrefix=download

I haven't yet gotten to provide improved instructions for non x86 tarballs...

[eitsupi]

@nathancarter I updated ghcr.io/rocker-org/devcontainer-features/quarto-cli to unblock arm64. (rocker-org/devcontainer-features#152) Thus the following devcontainer.json would work on arm64 machines.

{
    "image": "mcr.microsoft.com/devcontainers/base:debian",
    "features": {
        "ghcr.io/rocker-org/devcontainer-features/quarto-cli:1": {
            "version": "1.3"
        }
    }
}

[jimjam-slam]

So rad! Thanks @eitsupi and @dragonstyle!