mfisher87
commented
12 months ago Thank you for your report!
I lack an OSX system for testing this. Is anyone else willing to take this challenge on?
Open mdekstrand opened 12 months ago
mfisher87
commented
12 months ago Thank you for your report!
I lack an OSX system for testing this. Is anyone else willing to take this challenge on?
kelly-sovacool
commented
11 months ago I'm also seeing this problem on Linux x86_64
mfisher87
commented
11 months ago Thank you for reporting, @kelly-sovacool ! I am able to test on that platform, so I hope I can help you.
Can you provide more detail? I'm working with the Quarto conda package often on Linux x86_64 and haven't seen this issue yet. What version of the Quarto conda package (including build number) do you have installed?
Could you please open a new issue with requested details, and we'll continue discussing there?
Thanks again!
kelly-sovacool
commented
11 months ago @mfisher87 Thanks for following up! I realized my problem was due to a version installed from source clashing with the latest version installed from conda-forge. If I can figure out a reasonable reprex I'll open a new issue for it.
mfisher87
commented
11 months ago Very much appreciated, Kelly :)
mdekstrand
commented
11 months ago I can reproduce in a minimal x86-64 Linux environment:
$ micromamba create -n quarto -c conda-forge quarto
$ micromamba activate quarto
$ quarto
/home/michael/micromamba/envs/quarto/bin/quarto: line 158: /home/michael/micromamba/envs/quarto/bin/tools/deno-x86_64-unknown-linux-gnu/deno: No such file or directorySomething's definitely not right, but I'm still struggling to reproduce. After failing to reproduce on my local machine, I wanted to ensure there wasn't something special about my configuration that was causing this to work for me but not for you. So I attempted to reproduce with this Dockerfile:
FROM mambaorg/micromamba:1.5.1
ARG MAMBA_DOCKERFILE_ACTIVATE=1
RUN micromamba install -y -n base -c conda-forge quarto
RUN quarto create-projectStill, everything works as expected. Can you check env | grep QUARTO with your quarto environment activated and report back what you see? The QUARTO_DENO envvar should be set by {...}/envs/quarto/etc/conda/activate.d/quarto.sh to point to the correct location.
rawlins
commented
11 months ago For what it's worth, I haven't been encountering this issue on osx with the install shim in #22, though I'm still not exactly a heavy quarto user -- but preview etc seem to work fine. I have a fair amount less in the env in question (at least: no r stuff), so I'm guessing that in the diff between our package lists lies the answer. This current env that is working started with my quarto install workaround commands, and simply adds jupyter (and some specific packages for what I'm doing, mainly svgwrite, probably irrelevant to the issue at hand).
I'm not entirely sure how helpful this will be, but here's the details. This one I just spun up today but I hadn't noticed the issue before either.
conda list:
conda info:
mfisher87
commented
11 months ago @rawlins thank you for providing more details to help narrow this down! I don't see anything that jumps out now, but I expect this may be useful later :) I am still not certain what to ask or suggest next, so hopefully @mdekstrand 's answers to my questions above are enlightening :crossed_fingers:
Thanks also for putting the big walls of text in a <details> tag, I hadn't thought to do that before.
mdekstrand
commented
11 months ago Ahh, looking at the environment variables sheds light! It see that arm64 is a red herring — the true problem is using fish. When use bash, it works on both x86_64 Linux and OSX arm64.
Since the quarto shell script depends on environment variables set in etc/activate.d/quarto.sh to work, it only works on sh-compatible shells (bash, zsh). If I add a quarto.fish script to my Conda environment, then quarto --help works:
set -gx QUARTO_DENO /Users/michael/mambaforge/envs/quarto/bin/deno
set -gx QUARTO_DENO_DOM /Users/runner/miniforge3/conda-bld/quarto_1691275447155/_build_>
set -gx QUARTO_PANDOC /Users/michael/mambaforge/envs/quarto/bin/pandoc
set -gx QUARTO_ESBUILD /Users/michael/mambaforge/envs/quarto/bin/esbuild
set -gx QUARTO_DART_SASS /Users/michael/mambaforge/envs/quarto/bin/sass
set -gx QUARTO_SHARE_PATH /Users/michael/mambaforge/envs/quarto/share/quarto
set -gx QUARTO_CONDA_PREFIX /Users/michael/mambaforge/envs/quartoThanks Michael for updating the issue description! I did some research, and it looks to me like this is a broader conda problem that is unsolved, so I don't think there's much as a package maintainer I can do.
There is some recent activity in these discussions:
https://github.com/conda/conda/issues/7993 https://github.com/conda/conda/issues/6820
EDIT: After some deeper reading, I'm seeing a comment that suggests there is a little-known (undocumented??) way to define variables that will be set at activation time using JSON. My reading is that this issue applies regardless of whether the JSON mechanism is used or not. Migrating this feedstock to use the env_vars.d/quarto.json method would resolve this issue, I expect.
@mdekstrand what do you think? I may not have time to get to this in the next week, but if you want to give it a shot I'd be happy to support!
mdekstrand
commented
11 months ago @mfisher87 Thanks! It looks like the JSON option is quite intriguing — decreases the overhead of maintaining parallel activation scripts.
One thing I'm wondering, though — these env vars are all specifying predictable locations within the Conda environment. Would it be better to patch the quarto script to just detect these paths?
mfisher87
commented
11 months ago decreases the overhead of maintaining parallel activation scripts.
:100:
these env vars are all specifying predictable locations within the Conda environment. Would it be better to patch the quarto script to just detect these paths?
That's a good question. I want to make sure I think carefully about that because I'm the newest maintainer to work on this feedstock and I don't have the rationale of the maintainers who came before me.
I'd speculate that the motivation was to use established interfaces (envvars) over patching to maximize compatibility with future versions of Quarto. Since the script is already looking at these envvars, we can probably trust that the Quarto devs will be motivated to avoid breaking backwards compatibility with them.
:point_up: Don't read this as an argument against your idea, I'm just reasoning through this out loud :)
mfisher87
commented
11 months ago @mdekstrand I did some more research and opened an issue to document this feature :point_up:
Over there I've linked to a PR implementing the env_vars.d functionality in conda, and found source code which supports activating envvars specified in that manner in the Fish shell. I'm feeling confident this mechanism is the path to making this package more shell-agnostic.
Solution to issue cannot be found in the documentation.
Update: it seems the real problem isn't Mac, but the
fishshell —quartodepends on environment variables that are only set when the Conda environment is activated in a Bourne-compatible shell.Issue
After shimming in a version of
pandocto allowquartoto install (working around #22), running Quarto produced the following error:It seems that the Quarto script on osx-arm64 is looking in the wrong place for
deno(there is adenoin thebindirectory, so it should work).Installed packages
Environment info