Bump MSRV to 1.56.1

[tcharding]

As we have done in other parts of the ecosystem bump the MSRV to Rust v1.56.1.

Done for secp256k1 and secp256k1-sys.

This was originally in #688 but there are too many things going on so here it is separately.

[apoelstra]

Should also update clippy.toml and both READMEs.

[tcharding]

Ok, done properly now

git grep '1\.48'
CHANGELOG.md:22: * Bump MSRV to 1.48 [#595](https://github.com/rust-bitcoin/rust-secp256k1/pull/595)
secp256k1-sys/CHANGELOG.md:17: * Bump MSRV to 1.48 [#595](https://github.com/rust-bitcoin/rust-secp256k1/pull/595)

[apoelstra]

Heh, this breaks the vendoring script, which looks for patterns like x.y.z to find the version of secp256k1. Adding rust_version = "1.56.1" causes it to find two values, which derails the rest of the script.

The offending line is line 11 of secp256k1-sys/vendor-libsecp.sh which goes

DEFAULT_VERSION_CODE=$(grep version "$SECP_SYS/Cargo.toml" | sed 's/\./_/g' | sed 's/.*"\(.*\)".*/\1/')

We need to tighten this sed line.

To save you time I asked the chatbot to do it, which gave me

grep version "$SECP_SYS/Cargo.toml" | sed -n 's/version = "\([0-9]\+\.[0-9]\+\.[0-9]\+\)"/\1/p' | tr '.' '_'

which looks a lot more legit than my old code.

[tcharding]

The bot is way better at writing shell that we are - glad I don't depend on writing shell for a paycheck.

[apoelstra]

Lol, yeah. Shell has gotta be the biggest area where I'm not even close to its skill (and don't want to be :P).

[apoelstra]

Oh, but lol, I think in this case it still won't work. I think we need to change the initial grep version to grep '^version =' or something, so it doesn't match on rust_version =.

[tcharding]

The bot was wrong! I used ^ to only match on the start of the line. Not entirely sure if the quotes are needed but it works as is. FTR I was setting this value manually when I ran the script pereviously.

[apoelstra]

Hah, jinx.

[tcharding]

Ha, real time chatting on github.

[tcharding]

jinx again

[apoelstra]

ACK 2d0c783

[Kixunil]

This is also wrong - toml allows leading whitespaces.

Just kidding. I mean it is strictly wrong but nobody cares.

[apoelstra]

Would be nice if there were a tool like jq but for TOML.

We could try using Nix, which has a fromTOML builtin function, but I'd guess that most people do not want to maintain complicated logic in the Nix language, which combines laziness and dynamic typing in a truly impossible-to-read-or-debug way.

[Kixunil]

I just realized, would it make sense to rewrite our scripts in Nushell? It can convert Toml and a bunch of other formats to its own structured data representation. So this line would be just let version = (open Cargo.toml | get package.version). Also it handles structured data and error much better than bash but it's not as annoying when launching external programs as Python is. Though one big downside is we'd need to keep tests which we want contributors to run in bash to not annoy them too much.

I tried it out a long time ago (and even contributed a bit) so don't remember it that much but I'd love to learn it properly. I also have a nushell script wrapping lncli and converting string-encoded integers to normal integers (yes, they do that 🤦 ) if anyone is interested and I wanted to have a bitcoin-cli wrapper too. (IDK if it encodes ints as strings but at least outputting structured data would be nice.)

[apoelstra]

Sounds very interesting. I think I'd probably go Nix first, despite its shortcomings as a language, since it's a litte more mainstream (at least, within this project it is much more well-known). In Nix it's easy to hand off to bash and share code with bash.

[Kixunil]

Maybe Nushell is more appealing to learn than Nix based on your complaints? :) I find Nushell very readable. It does have dynamic typing but it's at least strong typing and some commands know their types upfront IIRC so they can report error messages nicely.