Update Rust toolchain to 1.86 and Related Deps

[peytonr18]

Summary

This PR bumps the MSRV/toolchain to Rust 1.86 to satisfy dependency requirements. Additionally, it updates the CI to use the new MSRV and updates the version of the following dependencies:

• nix to 0.31.1
• vergen-gitcl to 9
• whoami to 2

Resolves #276, #277, and #278

[cadejacobson]

Should we make an issue to review and potentially re-update this to be the stable 12 months ago in ~6 months?

[cjp256]

does 1.88 have any particular significance? What's the original purpose of the "12 months ago" pipeline? If it's meant to ensure it still builds for a particular target, I'd rather just update CI to build for that target directly. I suspect the E2E scenarios cover it, so maybe worth deleting

[peytonr18]

does 1.88 have any particular significance? What's the original purpose of the "12 months ago" pipeline? If it's meant to ensure it still builds for a particular target, I'd rather just update CI to build for that target directly. I suspect the E2E scenarios cover it, so maybe worth deleting

1.88 was the minimal MSRV version to make the dependencies work, but I think you're right. It makes more sense to just delete it and use stable only.

In that same vein, it probably makes sense to just update the MSRV to the latest stable version too to 1.93.0

[jeremycline]

does 1.88 have any particular significance? What's the original purpose of the "12 months ago" pipeline? If it's meant to ensure it still builds for a particular target, I'd rather just update CI to build for that target directly. I suspect the E2E scenarios cover it, so maybe worth deleting

I think it was a proxy for "make it easier for distributions to build", although that's a complicated space with how various distributions handle Rust. For example, Debian 13 ships Rust 1.85, and I presume it will continue to do that for the rest of its release (but I'm not very familiar with Rust in Debian). RHEL currently ships 1.88 right now but updates the toolchain every 6 months. Fedora ships 1.92, while Gentoo ships 1.91. I believe Debian is similar to Fedora in that they package all the dependencies and try very hard to have only one version of each library. This is, as you can imagine, difficult.

What's even more difficult is if you want to support Debian and Fedora, since Fedora is regularly bumping Rust and major versions of libraries and Debian is not. The second one of your dependencies introduces a major release with a MSRV higher than Debian, you're in trouble.

We could decide on a set of distributions to target and base dependency/MSRV selection based on that or decide to keep dependencies up to date even if that means using the latest release as MSRV

Another thing to consider it examining the dependencies and deciding whether there's better options or if they're truly necessary. You might find rustix to be a better fit than nix, as it has a stable release and a very conservative MSRV (I've also found cases where rustix provides better APIs in some cases, but I've not looked at recent nix releases so maybe the difference is minimal). vergen-gitcl looks to be there to provide a version based on git which you might be able to achieve without a dependency (particularly one with such an aggressive MSRV).

[dongsupark]

does 1.88 have any particular significance? What's the original purpose of the "12 months ago" pipeline?

In the beginning the CI did not have such a pipeline.
However, since Azure Linux folks told us issues about being unable to build azure-init with their toolchains with old Rust compiler versions, we introduced that in the CI.
So I would recommend talking to Azure Linux folks to know if those issues are still valid. If those issues were gone, then I am fine with deleting "12 months ago", and keeping only "stable".

/cc @SeanDougherty

And +1 on what @jeremycline said, it is always a huge pain to support old compiler versions.

[peytonr18]

RE: @jeremycline @dongsupark,

Thank you both for weighing in on this!

We synced offline this morning and landed on a "we'll cross that bridge when we get there" approach regarding versioning. Meaning, we'll do our best to support older compiler versions and as many distros as we can, but until we have a clear use case for packaging Debian 13, it's okay to use an MSRV slightly higher than the one they support. Presumably, they also have a patch or some mechanism for downgrading to version 1.85.0 that ca n be utilized in that scenario.

That being said, I think upgrading to the minimum version required by our current dependencies (1.88) seems like the most reasonable path forward. We can keep an eye out for any issues reported by users on older Rust versions and adjust if needed.

I’m also supportive of moving from nix to rustix, since that positions us better for maintaining a more conservative MSRV going forward. I’ll include that update in this PR.

I can spend some time exploring alternatives to vergen-gitcl, though I do think we were overdue for an MSRV increase anyway —1.74 is nearly 2.5 years behind the latest stable release. After this initial update, it might be helpful for us to align on a shared strategy for base dependencies and MSRV expectations.

Does this approach work for you both?

CC: @cadejacobson ; @cjp256

[SeanDougherty]

does 1.88 have any particular significance? What's the original purpose of the "12 months ago" pipeline?

In the beginning the CI did not have such a pipeline. However, since Azure Linux folks told us issues about being unable to build azure-init with their toolchains with old Rust compiler versions, we introduced that in the CI. So I would recommend talking to Azure Linux folks to know if those issues are still valid. If those issues were gone, then I am fine with deleting "12 months ago", and keeping only "stable".

/cc @SeanDougherty

And +1 on what @jeremycline said, it is always a huge pain to support old compiler versions.

Fwiw, Azure Linux is on 1.86 now, with 1.90 in preview right now

[jeremycline]

RE: @jeremycline @dongsupark,

Thank you both for weighing in on this!

We synced offline this morning and landed on a "we'll cross that bridge when we get there" approach regarding versioning. Meaning, we'll do our best to support older compiler versions and as many distros as we can, but until we have a clear use case for packaging Debian 13, it's okay to use an MSRV slightly higher than the one they support. Presumably, they also have a patch or some mechanism for downgrading to version 1.85.0 that ca n be utilized in that scenario.

That being said, I think upgrading to the minimum version required by our current dependencies (1.88) seems like the most reasonable path forward. We can keep an eye out for any issues reported by users on older Rust versions and adjust if needed.

I’m also supportive of moving from nix to rustix, since that positions us better for maintaining a more conservative MSRV going forward. I’ll include that update in this PR.

I can spend some time exploring alternatives to vergen-gitcl, though I do think we were overdue for an MSRV increase anyway —1.74 is nearly 2.5 years behind the latest stable release. After this initial update, it might be helpful for us to align on a shared strategy for base dependencies and MSRV expectations.

Does this approach work for you both?

I think that's a completely reasonable approach. It's very difficult to support both very new and very old Rust versions and so one shouldn't attempt it without justification. If your target audience ships a fairly modern toolchain, take advantage of it.