2

I have a specific problem, but understanding the solution I think is going to be useful in a broader context.

I have a project that indirectly depends on pnet; I don't directly reference it anywhere.

It was building fine for a few weeks with pnet version 0.22. On Monday, something changed and the version of pnet incremented to 0.23 and our CI server started failing to build.

It seems that moving forward, especially once we start deploying builds, being able to definitively reproduce exact outputs is going to be pretty critical for us, so this isn't specific to this library. This could really happen at any time with any library.

Is there a way in Cargo to somehow "force" the dependency tree to use the older version short of us pulling the source of the older pnet (and maybe whatever is using it)?

I'd love to just be able to put an entry into Cargo.toml that pins the old version.

I tried adding the following, but it didn't help:

pnet = "=0.22.0"
Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
ctacke
  • 66,480
  • 18
  • 94
  • 155
  • 1
    All dependency versions are pinned in the `Cargo.lock` file, so unless you change it (e.g. by invoking `cargo update`) the version of the dependency should not increase. – msrd0 Nov 08 '19 at 17:20
  • The CI server does a full, clean pull so it's not going to start with a cargo.lock – ctacke Nov 08 '19 at 17:23
  • 1
    Well you might need to add the `Cargo.lock` file to your repository in that case – msrd0 Nov 08 '19 at 17:24
  • 1
    Your `Cargo.lock` should be under version control, yep. – Ry- Nov 08 '19 at 17:31
  • 2
    The previous comments are misguided. You should **not** commit Cargo.lock **for a library**, see [What files in a Cargo project should be in my .gitignore?](https://stackoverflow.com/q/43667176/155423) and [Why do binaries have Cargo.lock in version control, but not libraries?](https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries). – Shepmaster Nov 08 '19 at 17:52
  • 1
    It looks like your question might be answered by the answers of [Can I force the use of my dependencies' Cargo.lock when resolving package versions?](https://stackoverflow.com/q/49723779/155423). If not, please **[edit]** your question to explain the differences. Otherwise, we can mark this question as already answered. – Shepmaster Nov 08 '19 at 17:53
  • See also [Set specific version of the dependency of a project's dependency in Cargo.toml or Cargo.lock](https://stackoverflow.com/q/27770031/155423). – Shepmaster Nov 08 '19 at 17:53
  • 3
    And to be clear, this is a bug in whatever crate(s) depend on `pnet`. According to the semver rules, versions 0.22 and 0.23 are **not guaranteed** to be compatible. Whoever specified the version of pnet was overly broad. You can use [cargo-tree](https://github.com/sfackler/cargo-tree) to identify what dependency pulls in pnet and submit an issue / PR to them to fix it. – Shepmaster Nov 08 '19 at 17:55
  • I'd already seen those answers and I guess I'd hoped that the state of the state today was better than what I was inferring from them. The challenge is that I'd not changed any dependencies, and all of a sudden the build started failing with a clean pull and compile. In the future we may need to be able to pretty precisely replicate a build, and I had hoped I could use this situation to learn how to get to that as well. – ctacke Nov 08 '19 at 18:02
  • *I'd hoped that the state of the state today* — In the future, you are encouraged to add bounties to an existing question if you think that the answers have grown outdated, instead of opening new questions and spreading knowledge across many different locations. At the very least, you should have linked to the questions you had already read and clearly described why you felt you weren't asking a duplicate. – Shepmaster Nov 08 '19 at 18:26
  • 1
    *to pretty precisely replicate a build* — you can, by using the `--precise` argument to Cargo, as mentioned. – Shepmaster Nov 08 '19 at 18:27
  • 1
    Ah, there it is. I was not seeing the forest for the trees. I was trying to get to it via the yaml rather than through a cargo update call in the build and therefore thinking this was similar but not the same. Thanks for shepherding me. – ctacke Nov 08 '19 at 18:50
  • @Shepmaster: I disagree, you should commit Cargo.lock for a library – assuming that this is the same advice that people give for libraries in other languages and not something somehow more specific to Cargo. It contains the history of the versions you test with. Just keep it up to date. (It isn’t published, right?) – Ry- Nov 08 '19 at 19:30
  • @Ry- You've got a point there, but official documentation recommends to only commit your `Cargo.lock` for binaries, not for libraries: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries – msrd0 Nov 08 '19 at 23:41
  • @msrd0: Yeah, I know, but its logic is that it doesn’t apply to end uses, which isn’t the point of using a lockfile with a library. It’s common advice in the Node world too, unfortunately (imo). – Ry- Nov 09 '19 at 02:43

0 Answers0