Quarto 1.3 won't install in pure osx-arm64 environment

[rawlins]

Solution to issue cannot be found in the documentation.

• [X] I checked the documentation.

Issue

I'm having trouble installing the current version of quarto from a pure conda-forge setup (miniforge); when I try to install it in a clean environment I get an unsuccessful attempt on frozen solve and then it will try to install:

quarto conda-forge/osx-arm64::quarto-1.2.475-hce30654_0

When trying to install the quarto version that is indicated as the current one on conda-forge in this clean env, it appears that the problem is a very narrowly pinned pandoc version (edit: exact command+output added):

$ conda install quarto=1.3.433                               [10:21:45]
Collecting package metadata (current_repodata.json): done
Solving environment: unsuccessful initial attempt using frozen solve. Retrying with flexible solve.
Solving environment: unsuccessful attempt using repodata from current_repodata.json, retrying with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: unsuccessful initial attempt using frozen solve. Retrying with flexible solve.
Solving environment: | 
Found conflicts! Looking for incompatible packages.
This can take several minutes.  Press CTRL-C to abort.
failed

ResolvePackageNotFound: 
  - pandoc[version='>=3.1.1,<3.1.2.0a0']

This can't be satisfied from conda-forge (which is my only channel here):

$ conda search -f pandoc                                     [10:24:24]
Loading channels: done
# Name                       Version           Build  Channel             
pandoc                        2.19.2      hce30654_1  conda-forge         
pandoc                        2.19.2      hce30654_2  conda-forge         
pandoc                         3.1.2      hce30654_0  conda-forge         
pandoc                         3.1.2      hce30654_1  conda-forge         
pandoc                         3.1.3      hce30654_0  conda-forge

So the only solution it finds is pandoc 2.19.2 and the old quarto version above.

Installed packages

# packages in environment at /Users/REDACTED/miniforge3/envs/quarto2:
#
# Name                    Version                   Build  Channel

Environment info

active environment : quarto2
    active env location : /Users/REDACTED/miniforge3/envs/quarto2
            shell level : 2
       user config file : /Users/REDACTED/.condarc
 populated config files : /Users/REDACTED/miniforge3/.condarc
          conda version : 23.5.0
    conda-build version : not installed
         python version : 3.10.12.final.0
       virtual packages : __archspec=1=arm64
                          __osx=13.2.1=0
                          __unix=0=0
       base environment : /Users/REDACTED/miniforge3  (writable)
      conda av data dir : /Users/REDACTED/miniforge3/etc/conda
  conda av metadata url : None
           channel URLs : https://conda.anaconda.org/conda-forge/osx-arm64
                          https://conda.anaconda.org/conda-forge/noarch
          package cache : /Users/REDACTED/miniforge3/pkgs
                          /Users/REDACTED/.conda/pkgs
       envs directories : /Users/REDACTED/miniforge3/envs
                          /Users/REDACTED/.conda/envs
               platform : osx-arm64
             user-agent : conda/23.5.0 requests/2.31.0 CPython/3.10.12 Darwin/22.3.0 OSX/13.2.1
                UID:GID : 147998184:174349480
             netrc file : None
           offline mode : False

[mfisher87]

Thanks for the issue report!

pandoc-feedstock started building for osx-arm64 with 3.1.2, so that's why pandoc 3.1.1 is not available for your system architecture. Near miss!

I'm not sure exactly what it looks like to do another build of pandoc 3.1.1 with osx-arm64 support, but I think that's the next step to resolving this issue without changing the build configuration for this feedstock.

However, if Pandoc is following semver (is it?), allowing these patch versions seems appropriate. This recipe currently gets the exact pandoc version pin from Quarto's source (the line in question). We could parse the version string from Quarto's source to only use the major and minor versions in these pins (i.e. 3.1.*)... @msarahan what do you think about this?

[mfisher87]

Looking at Quarto's packaging code and downloads page, I see that Quarto doesn't officially support osx-arm64 yet. Maybe there's no reason we can't if dependencies compatible with the ones Quarto normally bundles are available in conda-forge... but there's some work to do. Our osx-arm64 build succeeded but should have failed since pandoc 3.1.1 isn't available for osx-arm64. Haven't figured out why yet.

[rawlins]

Thanks! Makes sense that this is a mac/arm-specific issue. Looking around a bit I suspect that quarto may support arm64 on mac, and that the download there is a universal package. The packaging code linked is specific to pandoc, and looks like it's slated for an update soon in the official packaging. From that issue I think that they've been packaging Rosetta-based pandoc for mac pkgs previously.

This recipe currently gets the exact pandoc version pin from Quarto's source (the line in question).

Maybe I'm misunderstanding, but shouldn't export PANDOC=3.1.2 in the linked line translate to something more like pandoc[version='>=3.1.2,<3.1.3.0a0']? quarto commmit

[rawlins]

(Also, pandoc does not use semver but it looks to me like those versioning rules entail the crucial part of semver?)

[mfisher87]

Thanks for the added context! I'm fairly ignorant of Mac things. And most other things ;)

This recipe currently gets the exact pandoc version pin from Quarto's source (the line in question).

Maybe I'm misunderstanding, but shouldn't export PANDOC=3.1.2 in the linked line translate to something more like pandoc[version='>=3.1.2,<3.1.3.0a0']?

Apologies, I linked to the main branch. This is the correct line and point in history :) : https://github.com/quarto-dev/quarto-cli/blob/v1.3.433/configuration#L13

I had forgotten about this note in our recipe stating that both deno and pandoc tend to have compatibility issues across patch versions. I wonder if this comment is still true?

https://github.com/conda-forge/quarto-feedstock/blob/main/recipe/meta.yaml#L32-L38

[rawlins]

Thanks for the update, that clarifies things. Sounds like this may naturally resolve once quarto gets a version bump?

In the meantime, based on this discussion I think I have a pretty simple workaround for people with a similar setup to mine. The following seems to work to force the issue, and if I'm getting it right, mirrors how the official quarto install works:

conda install pandoc==3.1.1 -c conda-forge/osx-64
conda install quarto==1.3.433

Obviously, if you're trying to avoid mixing osx-64 packages as much as possible (which I am) I'd recommend this in a fresh env, as it may pull in other things (it did for me)...and if it's a conda setup that is already is allowing both archs this might have happened automatically, hence this not being reported before.

(I wonder if your test setup is allowing both archs? In principle there's no runnability problem mixing archs on current macs because of Rosetta, and I could imagine it's smoother to do that for CI; I'm not doing it because my experience last time I tried was that in practice you tend to end up with a confusing mess of archs, with all sorts of things running unnecessarily on Rosetta. But it will function.)

[mfisher87]

Thanks for the update, that clarifies things. Sounds like this may naturally resolve once quarto gets a version bump?

Sounds right to me! Thanks for sharing the workaround :100:

if it's a conda setup that is already is allowing both archs this might have happened automatically, hence this not being reported before.

This sounds right as well! I see now in your environment info in the OP, you've only got the osx-arm64 and noarch platforms in your channel list. Based on what you're saying, it sounds like an out-of-the-box miniforge installation on Apple Silicon would also allow osx-64, and the Rosetta emulator would enable those to work. Makes sense.

(I wonder if your test setup is allowing both archs? In principle there's no runnability problem mixing archs on current macs because of Rosetta, and I could imagine it's smoother to do that for CI; I'm not doing it because my experience last time I tried was that in practice you tend to end up with a confusing mess of archs, with all sorts of things running unnecessarily on Rosetta. But it will function.)

This also sounds right. I think it would be nice test that packages can be installed without needing to emulate, but I imagine many packages might still fail that test.

[SaravananSathyanandhaQC]

Just to say Quarto 1.4 will install in pure osx-arm64 environments now :)

[mfisher87]

Woo! I think we should close this issue and ask people to use 1.4 if they face this. I don't have the hardware to work on this anyway, and I don't know anyone else in the maintenance team who does.

What do you think?

[rawlins]

Great, a quick test of simple conda install quarto in a fresh env gets quarto 1.4.550 (with pandoc 3.1.11.1) and no problems, so as far as I'm concerned this can be closed. As the original reporter I'll go ahead and do that, though feel free to reopen if a maintainer does want quarto 1.3 to work with this configuration. Thanks to whoever got this to happen!

[mfisher87]

Awesome, thanks @rawlins! I'm all for rolling forward. If there's a good case for fixing this in 1.3, someone will let us know :)