-
-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pandoc installed and used is higher than the one supported by Quarto #58
Comments
Let me details the problem here. Quarto is supposed to work and use Pandoc 3.2 as defined in configuration file and conda-forge read this quarto-feedstock/recipe/meta.yaml Line 6 in 367d311
So it may consider it as a usual version spec, and probably thinking that Pandoc 3.2.1 is an ok version. But it is not. Quarto expect this 3.2 version only. Bundling for conda-forge requires a pinned version of dependency so that the right one is used. Hopefully this is possible. Confirmation that 3.2.1 is the one installed.See log for
whereas Quarto is configuring with 3.2 |
I believe the build dependency version is set correctly here to quarto-feedstock/recipe/meta.yaml Line 29 in 367d311
But then here we set the runtime dependency to ... I think.... quarto-feedstock/recipe/meta.yaml Line 38 in 367d311
from conda_build.jinja_context import pin_compatible
from conda_build.metadata import MetaData
metadata = MetaData.fromdict({
'requirements': {'build': ['pandoc 3.2']},
'package': {'name': 'foo', 'version': '0.1.0'},
})
print(pin_compatible(metadata, "pandoc", max_pin="x.x.x")) If I understand correctly, the runtime specification we want is "exactly 3.2, not 3.2.1 or anything else". I don't think it's possible to generate the specification we want with Does this sound correct to everyone? |
@cderv based on this comment by you in the upstream repo, do you think we need to apply the same change to every runtime dependency whose version we read from
|
yes exactly.
Quarto is built and tested in main repo against the exact version of the dependency. There is no warranty that it will work with other version, including newer. Which is proven by the Pandoc bug of a new version. So yes I think we need to make sure that the configuration are exact match. We do this for now. quarto-feedstock/recipe/meta.yaml Lines 24 to 44 in 367d311
I don't know enough about conda build process but why do we have different version for build and run ? |
I'm not sure, many of those choices were made before I started as a maintainer! Perhaps the exact match wasn't available on conda-forge.
We are currently doing that with |
Somehow for deno and deno_dom is works as is it seems. correct version seems to be installed. Maybe because it don't have the a.b(.c) version problem. |
That certainly sounds plausible! For now, let's ensure that the pandoc runtime pin exactly matches the build pin, which is read exactly from |
Solution to issue cannot be found in the documentation.
Issue
I've described at quarto-dev/quarto-cli#10682 an issue I've been having with the
conda-forge
version ofquarto
.Issue
With using quarto render file.qmd --to pdf on
when
file.png
exists in the directory, LaTeX compilation fails withIt looks to me like the \pandocbounded function added to pandoc on 3.2.1 is not defined in some step of the rendering.
Error is given on
but with downgrading via
mamba install "pandoc<3.2" quarto
everything is ok:Extra
The developers over there also highlighted that the feedstock should be following dependencies outlined in here though perhaps that is a separate issue.
Installed packages
Environment info
The text was updated successfully, but these errors were encountered: