3 ms·

> When I did that, despite having not changed any dependencies, I got a build error in CI/CD. Isn't this resolved by passing `--locked` to `cargo`? If you don

> When I did that, despite having not changed any dependencies, I got a build error in CI/CD. Isn't this resolved by passing `--locked` to `cargo`? If you don't want it to resolve deps, don't let it. This isn't bit rot. This lament seems similar to "I can't compile this Rust code (using an older version of rustc)".

steveklabnik 2y ago
The issue is the opposite of --locked: the older version of the dependency was the one causing the issue. To fix it, you need to update the dependency, not keep the one in the lockfile. Also, in this case specifically, --locked would be a no-op. Rust doesn't automatically upgrade dependencies unless you either change your Cargo.toml, or run cargo update to change your Cargo.lock. The author didn't change any dependencies, none of their versions changed, and so --locked wouldn't have changed that the failure happened.
- mustache_kimono 2y ago
  > The issue is the opposite of --locked Shows what I know! So -- it's type inference of a new rustc and an old dep? That's much more interesting.
  - steveklabnik 2y ago
    Yes, this is Rust 1.80.0 not being able to compile code that worked with 1.79.0. The vast, vast majority of the time, you don't need to worry about that, but every once in a while, something like this happens. There are limited times when it's permissible, and often steps are taken to limit the blast radius. The only reason people are noticing this is because time is such a popular dependency. And the fact that it was noticed and fixed before release is a success story for that release process, as users didn't have to wait for a fix, and could get their code fixed immediately.
    - ucirello 2y ago
      I am not sure any of what you described can be declared a success in any sense. Failure #1: The language deployed a non-backward compatible change. Failure #1b: and their ecosystem thinks that's OK. Failure #2: users only saw the need to upgrade the dependency because the language broke that dependency first. So unless they had some other reason to update the given dependency ahead of the compiler upgrade, they would be hit by the problem no matter what. Failure #3: downplaying The importance of the breakage by implying the blast radius would've been smaller if the victim of the first two failures was a lesser known dependency. I can't see any success - of the release process or in any other way. And finally, framing a failure as success is one central problem I have with Rust ecosystem's toxic positivity. In any other healthy community the answer would be "OK, we made a mistake, let's run a post-mortem and do better", or even plain embarrassment - but Rust's ecosystem is the only one in which there's a failure in the joint of two releases processes and claim it as a "success story for [one of the] release process". My hope, as bigger games adopt Rust (US Gov, MS, Linux etc) these attitudes will change.
      - hulitu 2y ago
        > My hope, as bigger games adopt Rust (US Gov, MS, Linux etc) these attitudes will change. It is going on since some years with no change in sight.
      - steveklabnik 2y ago
        You can make an abstract argument as much as you'd like, but Rust toolchain upgrades cause the least churn of any ecosystem I've worked with in the past 25 years of being a software developer. That includes C projects. I've spent more time writing Hacker News comments about this than I did dealing with it.
      - mustache_kimono 2y ago
        > Failure #1: The language deployed a non-backward compatible change. I guess I'm trying to understand how this is particular to Rust. Isn't this something that can happen in any language which uses type inference? I wonder how other languages resolve. It may be fair to say -- "if you rely upon type inference, the algo isn't guaranteed not to change" as a caveat on backwards compatibility. > And finally, framing a failure as success is one central problem I have with Rust ecosystem's toxic positivity. Yeesh. The rending of garments is just too much.

steveklabnik 2y ago

The issue is the opposite of --locked: the older version of the dependency was the one causing the issue. To fix it, you need to update the dependency, not keep the one in the lockfile. Also, in this case specifically, --locked would be a no-op. Rust doesn't automatically upgrade dependencies unless you either change your Cargo.toml, or run cargo update to change your Cargo.lock. The author didn't change any dependencies, none of their versions changed, and so --locked wouldn't have changed that the failure happened.

mustache_kimono 2y ago
> The issue is the opposite of --locked Shows what I know! So -- it's type inference of a new rustc and an old dep? That's much more interesting.
- steveklabnik 2y ago
  Yes, this is Rust 1.80.0 not being able to compile code that worked with 1.79.0. The vast, vast majority of the time, you don't need to worry about that, but every once in a while, something like this happens. There are limited times when it's permissible, and often steps are taken to limit the blast radius. The only reason people are noticing this is because time is such a popular dependency. And the fact that it was noticed and fixed before release is a success story for that release process, as users didn't have to wait for a fix, and could get their code fixed immediately.
  - ucirello 2y ago
    I am not sure any of what you described can be declared a success in any sense. Failure #1: The language deployed a non-backward compatible change. Failure #1b: and their ecosystem thinks that's OK. Failure #2: users only saw the need to upgrade the dependency because the language broke that dependency first. So unless they had some other reason to update the given dependency ahead of the compiler upgrade, they would be hit by the problem no matter what. Failure #3: downplaying The importance of the breakage by implying the blast radius would've been smaller if the victim of the first two failures was a lesser known dependency. I can't see any success - of the release process or in any other way. And finally, framing a failure as success is one central problem I have with Rust ecosystem's toxic positivity. In any other healthy community the answer would be "OK, we made a mistake, let's run a post-mortem and do better", or even plain embarrassment - but Rust's ecosystem is the only one in which there's a failure in the joint of two releases processes and claim it as a "success story for [one of the] release process". My hope, as bigger games adopt Rust (US Gov, MS, Linux etc) these attitudes will change.
    - hulitu 2y ago
      > My hope, as bigger games adopt Rust (US Gov, MS, Linux etc) these attitudes will change. It is going on since some years with no change in sight.
    - steveklabnik 2y ago
      You can make an abstract argument as much as you'd like, but Rust toolchain upgrades cause the least churn of any ecosystem I've worked with in the past 25 years of being a software developer. That includes C projects. I've spent more time writing Hacker News comments about this than I did dealing with it.
    - mustache_kimono 2y ago
      > Failure #1: The language deployed a non-backward compatible change. I guess I'm trying to understand how this is particular to Rust. Isn't this something that can happen in any language which uses type inference? I wonder how other languages resolve. It may be fair to say -- "if you rely upon type inference, the algo isn't guaranteed not to change" as a caveat on backwards compatibility. > And finally, framing a failure as success is one central problem I have with Rust ecosystem's toxic positivity. Yeesh. The rending of garments is just too much.