Can rust-version be set separately under [[bin]] or somehow actually correctly identify the CLI vs. Library MSRV?

Hm, there is the option of extracting the lib/bin into separate packages, where the bin package will depend on the lib package. This way, the bin package can specify a "recent" rust-version, and the lib package can put some effort into supporting older versions of rustc. In particular, the clap dependency would probably move into the bin package entirely, and so no change to the locked versions of dependencies would be needed. Doing that might be a bit annoying for downstream users, since either the binary or library would have to change name.

Maybe there's a better way, but not one I know of.

I suppose one solution would be to extract the lib into its own package (say pulldown-cmark-lib), and then reexport the entire lib package in the bin package.

@alerque I put together a proposal that separates the library/binary into distinct crates, only to realise that it was never the binary that was pulling in clap; rather it was criterion, used for the benchmarking suite and specified under dev-dependencies.

Since clap is "just" a dev dependency, I don't think it will actually propagate to any package depending on this package, which means there shouldn't be any concern in terms of packaging until someone wants to actually package this lib/bin itself and therefore want to run the test suite 🤔 let me know what your opinion is as to what should or should not be done.

OK. Please check the failing tests in the automated build.

I don't see as a bad thing separating lib and bin in different crates in this way because the former pulddown-cmark crate can still be used as the lib as before. However, if this is not necessary because the problem is in the dev dependencies, I think a better solution is separating MSRV for use and dev and using the dev MSRV in the Github actions toolchain.

clap is just used for fuzzer. How about replacing it with getopts? The getopts crate is already used in src/main.rs. So we can happily remove clap with no additional dependency and reduce the MSRV. It might also be a good idea to downgrade the clap version to match to the reduced MSRV.

Hmm, I'm not understanding why clap affects MSRV of this crate actually. clap is only used in the fuzzer.

The fuzzer is not included in pulldown-cmark crate nor pulldown-cmark-escape crate. So it should not affect those crates shipped on crates.io at all. Can't we simply downgrade MSRV to 1.71.1 if only clap crate is the blocker?

I tried to downgrade the version on my local and cargo check didn't complain it.

diff --git a/pulldown-cmark/Cargo.toml b/pulldown-cmark/Cargo.toml
index 42ce426..13527a2 100644
--- a/pulldown-cmark/Cargo.toml
+++ b/pulldown-cmark/Cargo.toml
@@ -11,7 +11,7 @@ repository = "https://github.com/raphlinus/pulldown-cmark"
 keywords = ["markdown", "commonmark"]
 categories = ["text-processing"]
 edition = "2021"
-rust-version = "1.74" # Update README.md and GitHub action when changing this
+rust-version = "1.71.1" # Update README.md and GitHub action when changing this
 readme = "../README.md"
 exclude = [
     "/third_party/**/*",

I think the issue is that the dev dependency criterion is pulling in clap. It’s not clear to me what the best practice is regarding MSRV and dev dependencies.

Does dev-dependency affect rust-version? The rust-version field is for library users. And dev-dependencies are not installed on a user installing the crate. So if my understanding is correct it does not affect.

Recent URLO discussion:

https://users.rust-lang.org/t/rust-version-and-development-dependencies/112608

So I think the MSRV can be lowered. We just need to check that the library compiles with the advertized MSRV in CI. README should be clear that there are two different MSRVs for the library and benchmarking/other tools.

Yes, having two different MSRVs seems the best option.

@Martin1887 I created an alternative PR for this issue at #916. Would you take a look?