You also need cargo update -p schemars --precise 0.8.3

I didn't see this before opening #1697. But:

• We don't actually need to pin schemars to compile with 1.41.1. We do need to pin url (2.2.2) and form_urlencoded (1.0.1).
• However Jeremy's test fails, on all compilers, with schemars >0.8.3.

So I dunno, maybe the pin was correct.

That's not right, version of cargo is irrelevant. The reason it's wrong is if a different crate requires higher version those will be incompatible leading to at best duplication, at worst impossibility to compile.

Cool, thanks for the explanation.

We don't actually need to pin schemars to compile with 1.41.1.

I discovered this too but the versions of schemars used by hashes and extended_tests/schemars have to be the same when running extended_tests/schemars tests, and the tests fail without pinning so I'm guessing dowstream users will hit problems too if they do not pin. Did not verify that assumption.

The new README text is kinda misleading. You do need to pin schemars ... but this has nothing to do with the MSRV. For the MSRV you just need to pin url and formurll_encoded.

I'm a bit confused then,

rust-bitcoin

• cargo test --features=schemars - works fine
• cd hashes && cargo +1.41.1 test --features=schemars - works fine (can't use this command in workspace root with +1.41.1 for some reason)

extended_tests/schemars_test

• cargo test fails unless schemars is pinned with --precise 0.8.3
• cargo +1.41.1 test fails unless schemars, url, form_urlencdode are all pinned

The answer doesn't matter really, I could have easily made a mistake while checking every combination I could think of.

I changed hashes/README.md to be a hopefully loose enough to not be misleading and correct enough to help users out (based on your comment @apoelstra)

@tcharding to use 1.41.1 you need to pin url and form_urlencoded. There is no need to do this unless you are using 1.41.

To use schemars at all you need to pin schemars. Which begs the question of why we are unpinning it at all.

To use schemars at all you need to pin schemars

Do you mean the test failure after doing the following?

0. vim Cargo.toml - remove the pin
1. cd extended_tests/schemars
2. vim Cargo.toml - remove the pin
3. cargo test

I printed the error:

ValidationError { msg: "Invalid type.", instance: Some(String("6cfb35868c4465b7c289d7d5641563aa973db6a929655282a7bf95c8257f53ef")), schema: Some(Object {"$schema": String("http://json-schema.org/draft-07/schema#"), "description": String("Output of the SHA256t hash function."), "items": Array [Object {"maxLength": Number(64), "minLength": Number(64), "pattern": String("[0-9a-fA-F]+"), "type": String("string")}], "maxItems": Number(1), "minItems": Number(1), "title": String("Hash_for_TestHashTag"), "type": String("array")}), instance_path: [], schema_path: ["type"] }

If I understand it correctly the type is OK, just jsonschema_valid thinks it's not? (In hurry so good chance I'm wrong.)

Do you mean the test failure after doing the following?

Yes, I mean that test failure. I wasn't able to print the error because somehow nothing returned by the failing assert implements Debug. And I don't know what jsonschema_valid is or how it relates to schemars.

The schema generated is wrong because schemars is interpreting the struct tuple as a JSON array.

Can be easily solved by:

#[cfg(feature = "schemars")]
impl<T: Tag> actual_schemars::JsonSchema for Hash<T> {
    fn schema_name() -> String {
        "Hash".to_owned()
    }

    fn json_schema(gen: &mut actual_schemars::gen::SchemaGenerator) -> actual_schemars::schema::Schema {
        crate::util::json_hex_string::len_32(gen)
    }
}

To use schemars at all you need to pin schemars.

I think its better to unpin it and every other dependency and just pin using Cargo.lock with the commands to pin dependencies since it prevents rust-bitcoin for being packaged easily, for example, in GNU Guix as it provides schemars@0.8.8 which is not compatible with the current version spec, so one has to go and patch the Cargo.toml of the crate to be able to use it with newer versions. So that needs to be done for every pinned crate where a new version is available.

I think that's true for other distros that provide only a single version of a package instead of including all of the minor versions needed.

That would also effectively remove the need to pin other crates that we don't use directly in the Cargo.toml and allows to rename actual-schemars to schemars.

@jeandudey thanks for the fix!

We are all onboard with removing pins (all of them). The issue is that nobody besides you in this conversation has ever actually used schemars, the person who originally advocated for its inclusion is no longer working on it, and they evidently made some breaking change between 0.8.3 and 0.8.4 which is causing our only test case to break.

Implemented all review suggestions, thanks crew.

Done reviewing d02a984a1906fd5175e0e7eed7e54e0fed2d554f. Looks good, but I would like the shebang to be fixed.

Fixed shebang and added redirect as requested. No other changes.

Please see PR description for what is in the last force push. Don't be surprised If I've confused you, I confused myself there for a bit.

Actually, it should be removed because of #1763 Sorry about the noise.

I don't follow - this is a feature guard, nothing to do with docs?

EDIT: Ignore this comment by me, I was confused.

Hey @Kixunil can you take a look at this one please, I think your suggestion ways misplaced unless I'm misunderstanding you. #1696 (comment)

Is there a reason for you not ack'ing this one @Kixunil?

Force push is to fix multiple types s/serder/serde in the commit log and also in one of the readmes. No other changes.