Installing cargo-deny fails

[sophie-h]

Current behavior 😯

cargo install cargo-deny fails with

   Compiling gix-attributes v0.22.1
   Compiling gix-url v0.27.1
   Compiling gix-ref v0.41.0
   Compiling gix-traverse v0.37.0
   Compiling gix-credentials v0.24.1
error[E0599]: the method `context` exists for fn item `fn(&mut &[u8]) -> Result<SignatureRef<'_>, ErrMode<_>> {decode::<'_, _>}`, but its trait bounds were not satisfied
   --> /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/gix-ref-0.41.0/src/store/file/log/line.rs:142:46
    |
142 |                 gix_actor::signature::decode.context(StrContext::Expected("<name> <<email>> <timestamp>".into())),
    |                                              ^^^^^^^ method cannot be called due to unsatisfied trait bounds
    |
    = note: the following trait bounds were not satisfied:
            `<for<'a> fn(&'a mut &[u8]) -> Result<SignatureRef<'_>, winnow::error::ErrMode<_>> {gix_actor::signature::decode::<'_, _>} as FnOnce<(&mut _,)>>::Output = Result<_, ErrMode<_>>`
            which is required by `for<'a> fn(&'a mut &[u8]) -> Result<SignatureRef<'_>, winnow::error::ErrMode<_>> {gix_actor::signature::decode::<'_, _>}: winnow::Parser<_, _, _>`
            `<&for<'a> fn(&'a mut &[u8]) -> Result<SignatureRef<'_>, winnow::error::ErrMode<_>> {gix_actor::signature::decode::<'_, _>} as FnOnce<(&mut _,)>>::Output = Result<_, ErrMode<_>>`
            which is required by `&for<'a> fn(&'a mut &[u8]) -> Result<SignatureRef<'_>, winnow::error::ErrMode<_>> {gix_actor::signature::decode::<'_, _>}: winnow::Parser<_, _, _>`
            `<&mut for<'a> fn(&'a mut &[u8]) -> Result<SignatureRef<'_>, winnow::error::ErrMode<_>> {gix_actor::signature::decode::<'_, _>} as FnOnce<(&mut _,)>>::Output = Result<_, ErrMode<_>>`
            which is required by `&mut for<'a> fn(&'a mut &[u8]) -> Result<SignatureRef<'_>, winnow::error::ErrMode<_>> {gix_actor::signature::decode::<'_, _>}: winnow::Parser<_, _, _>`
    = help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
    |
76  +     use winnow::parser::Parser;
    |
   Compiling gix-index v0.29.0
   Compiling gix-ignore v0.11.1
   Compiling gix-revision v0.26.1
   Compiling gix-packetline-blocking v0.17.3

Expected behavior 🤔

Trying it here first since it looks like a gix regression on first glance.

Git behavior

No response

Steps to reproduce 🕹

No response

[Byron]

It looks like winnow has changed something in a patch release that was ultimately breaking. This can always happen and cargo install without the --locked argument is prone to such failures.

Please use --locked as workaround.
Closing, as I don't think this is anything that can be fixed here, and even if it was (like backports) its not feasible.

CC @epage (author of winnow)

[Byron]

Sometimes I am driven by wishful thinking, but this is a fallout and it's probably easiest to fix it from here.

[Byron]

This should be fixed now. I investigated the update issue of gix-ref and why it wouldn't pull in the latest version of it, and it turned out that it was all based on other patch-releases needing gix-actor in the latest version, so the resolver did the right thing and found a lower version of gix-ref which was compatible with the latest version of gix-actor, at least on paper.

Since I wasn't really able to produce a gix-ref which can work with both versions of gix-actor as it would then have to mix winnow 0.5 and 0.6 which doesn't work, I decided to yank gix v0.59 entirely as it's the least used.

The culprit here is that an upgrade to winnow 0.6 happened without me realizing that this is a breaking change as it's not perfectly isolated. gix-actor for instance leaks an error type (for good reason), but that's also causing the issue.

In future, and it's something I usually do, I have to treat breaking winnow upgrades as breaking for the API, and even though it's something I kind-of know, this time it slipped by in the reviews. As the upgrade was contributed, it was less obvious to me I suppose, but I have to be more vigilant.

My greatest apologies for the disruption this has caused :/.

[epage]

Public dependencies with cargo semver-check for them would help.

I should have chosen Conventional Commit style in #1290 and marked the commit as breaking

• When making changes in isolation, its easy to forget whats public or not
• Upgrading all packages to the new dependency at once obscures makes it harder to notice these distinctions and makes it harder to track which packages were affected by a breaking change.

I suspect a couple of aspects that made this more likely to happen

• Exposing winnow in public APIs in crates that aren't just straight parsers where everything is using winnow
• The hybrid Conventional Commit style used in this repo where the commit style is based on whether its user facing or not, rather than based on feat, fix, docvsrefactor, test, chore, style`.