pandoc 1.14 compatibility

[agitter]

I noticed panflute 2.1 supports pandoc versions 2.11.0.4—2.13.x. Are there any known incompatibilities with the very recently released pandoc 2.14.x?

[dhimmel]

The issue for us is that the panflute-feedback for conda-forge is adding the pandoc version to the requirements:

# exclusive
{% set pandoc_maximum_version = "2.14" %}
...
requirements:
  run_constrained:
    - pandoc >={{ pandoc_minimum_version }},<{{ pandoc_maximum_version }}

My understanding is that the Pandoc types API version is all that actually matters for filter compatibility, not the pandoc version. So if Pandoc 2.14 still uses pandoc-types 1.22, there won't actually be any issues.

So would it be fair to say that the issue here is that the panflute readme preemptively stated that 2.14 wasn't compatible, even though it ended up being compatible. And then the panflute-feedback developers codified that in the conda recipe?

[sergiocorreia]

Hi Anthony, Daniel,

No, there are no problems that I'm aware of (in fact, I currently have Pandoc 2.14 installed and I have been using Panflute quite extensively in the last weeks without issue).

I'm not very familiar with panflute-feedstock; I believe @ickc might be more familiar with it. One option for the future is to just use open-ended version requirements and remove maximum versions, as usually panflute works without issues (with some rare exceptions).

[ickc]

I can spend some time on this in a few days.

In the case of conda, since pandoc is available with that package manager, the proper way to manage the version would be constraining the pandoc version as well.

It is true that panflute should mainly depends on the pandoc-types API only. But we should not be claiming compatibility (to future pandoc versions) without testing panflute against it first. In fact, panflute 2.0 didn't automatically be compatible with pandoc 2.12, 2.13, because of a minor but breaking change. In fact, pandoc following Haskell's versioning is actually major.major.minor.critical. So 2.13 to 2.14 jump is supposed to be a breaking change.

So my point is we should better be safe than sorry. If anyone want to upgrade to a newer version of pandoc, (and no one else is doing it yet,) they should first use the CI to test against newer pandoc, fix things if there's any thing needed fixes, if not, no new panflute version is needed, update the pandoc supported version table in README, push change to pandoc-feedstock with new constraint while incrementing the build no. (as the pandflute version is not incremented.)

[agitter]

@ickc that process makes sense to me.

Regarding the panflute CI testing, I don't anticipate anything will need to be fixed this time. If I'm reading the build logs correctly, the tests against pandoc latest are passing successfully with pandoc 2.14.x. One example from fa17590.

[ickc]

For change like this that no modification on panflute is needed to support newer pandoc, the steps necessary are straight forward:

1. explicit test against newer pandoc: https://github.com/ickc/panflute/actions/runs/930870182 (this test both 2.14 and 2.14.0.1)
2. document it in README: 242a3de (no need to increment panflute version as no code change, i.e. no PyPI upload as well)
3. in conda-forge, increment pandoc_maximum_version and build number: https://github.com/conda-forge/panflute-feedstock/pull/12/files

Welcome anyone to create PR for situation like this to help the pandoc filter ecosystem stays up-to-date.

[dhimmel]

Thanks @ickc for conda-forge/panflute-feedstock#12. Once the panflute README is updated, I think this issue can be closed.

[dhimmel]

The README is still outdated, which was the root cause of the conda-forge incompatibility:

Would it make sense to keep this issue open until the README is updated?

[ickc]

See #193.

I think since the remaining thing is a matter of documentation, it should be regarded as closed.

(But I agree this is not a clear-cut situation if we should keep it open or not.)

[dhimmel]

Ah I see, it's updated in 242a3de, which is part of #193.