v0.3.13.0

[mfansler]

Checklist

• [x] Used a personal fork of the feedstock to propose changes
• [x] Reset the build number to 0 (if the version changed)
• [x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [x] Ensured the license file is being packaged.

Upstream has a dependency on pandoc-types, but I don't find this on Conda Forge - do we need a new feedstock for this?

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[mfansler]

@conda-forge-admin, please rerender

[github-actions[bot]]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/pandoc-crossref-feedstock/actions/runs/2381711645.

[mfansler]

All is passing, but please comment on pandoc-types before merging (not my expertise):

Upstream has a dependency on pandoc-types, but I don't find this on Conda Forge - do we need a new feedstock for this?

Even if we don't need it for build or run, perhaps we should be adding bounds under run_constrained.

[mfhepp]

Maybe @jgm or @tarleb could help clarify this and remove this blocker? My purely gut feeling is that the dependency is not needed for pandoc-crossref and provided by pandoc itself. But it would be good to get this out of the way.

[tarleb]

I'd be happy to help, but not sure if I understand the issue. Is the question if pandoc-crossref should depend on pandoc-types?

Maybe this info helps: pandoc-crossref depends on pandoc-the-library, not pandoc-the-executable. Because of that it has a transitive dependency on pandoc-types on build-time. Does that help?

[mfhepp]

Thanks, @tarleb for this info! I do not really understand the mechanics of conda feedstocks, but if I get it right, then if it builds locally, it should also work for conda-forge.

As @knaaptime also reviewed and approved of this pull-request, I would recommend going forward and merge the PR.

I will be happy to test and provide feedback once it it live on conda-forge.

[mfansler]

@tarleb yes, that helps. We can omit it from the recipe definition because we redistribute the executable from upstream.

@mfhepp thanks for helping move this forward!

[mfhepp]

You are very welcome!