Decide on an MSRV Policy

[emmatyping]

For compatibility with the many platforms CPython ships on, we should select a minimum supported Rust version for CPython.

Things to consider when doing so:

• Going backwards in versions might be hard, as new features could be critical to how we design abstractions.
• 1.85 introduces Rust 2024, which has several nice improvements
• We should consult with Linux distribution maintainers as part of this selection

[youknowone]

Rust 1.88 stablized let chain, which enhance coding experience for complex if statements

[epage]

https://doc.rust-lang.org/cargo/reference/rust-version.html explores MSRV considerations.

Huh, something I'm not finding on that page is discussion of development MSRV vs production MSRV. What this means is what versions are needed or allowed during development vs what is needed just to build a production binary. This distinction is important for a couple of reasons

• If a higher development MSRV is required, then those steps that require it can't be done on the production binary. For instance, if you have a test dependency that requires a higher MSRV, then you can only verify your MSRV for compile time and not runtime.
  • There might be some things where this is fine. For instance, you might feel that not benchmarking on the production MSRV is an acceptable risk, so you can have your benchmarks in a separate package that has a higher MSRV or no MSRV
• If you require your production MSRV for development (e.g. using rust-toolchain.toml file), you prevent people from leveraging new development-time features
  • I also find it annoying when contributing to a project to suddenly pull in a new toolchain

On a related note, you need to decide what version to lint on. Lints change across releases and more can be added. If you turn warnings into errors in CI, this can break CI on a new release. I pin the CI lint job to a specific Rust version and have RenovoateBot post PRs updating it to the latest version. I used to use my MSRV for that but that was annoying in development when I saw a bunch of warnings I couldn't do anything about. It also meant I had to live with lint bugs and live without new lints.

When considering an MSRV, you'll also need to take #3 into account

• It currently lists build-std as required, not just a nice to have, meaning you need nightly until it is approved and stabilized.
• Tracking issue for RFC 2523, #[cfg(version(..))] rust-lang/rust#64796 would make it easier for you and dependencies to support a range of Rust versions. If/when it is stabilized, it will either require that version for the MSRV or only be able to check between that version and previous versions
• There are packages in the community for this but they increase build times and you would have to keep using it until you were willing to bump your MSRV for whatever Tracking issue for RFC 2523, #[cfg(version(..))] rust-lang/rust#64796 allowws

[Kivooeo]

Yes please don't select version below 1.88, I want to use let chains :3

[emmatyping]

I expect the limiting factor will likely be Linux distro support, so I think we should reach out to them first. My inclination is "at most latest - 2 versions, and then pick based on what linux distributions support"

When considering an MSRV, you'll also need to take #3 into account

It currently lists build-std as required, not just a nice to have, meaning you need nightly until it is approved and stabilized.

I think build-std is probably eventually required. We can start without it, and run sanitizers on nightly.

rust-lang/rust#64796 would make it easier for you and dependencies to support a range of Rust versions.

This does seem nice! Perhaps we should add this to #3

[epage]

I expect the limiting factor will likely be Linux distro support, so I think we should reach out to them first. My inclination is "at most latest - 2 versions, and then pick based on what linux distributions support"

I'd recommend also talking to burntsushi as they have done some of the distribution research in the past.

[emmatyping]

I've been thinking about this for a bit, and realized that currently the experimental JIT requires ~the newest released version of clang. While Rust for CPython remains experimental, I think we can probably track a relatively new version of Rust.

So how about for now we set the MSRV to the latest stable version - 2. We can re-evaluate this once we have a bit more experience with it.

[Kivooeo]

yeah, sounds fine to me, it shouldnt be perfect at the start, it seems more important to start and then see how it goes, and when we get some experience in this, some experience adopting rust into python, then we could revisit it if any adjustments are needed

[alex]

For cryptography what we found is that once we had wheels for basically every platform (musllinux was the biggest one not available when we first shipped rust) we had a lot more ability to raise our MSRV -- and we could use data from PyPI to guide what was practical.

It's not really clear to me how, if at all, this translates to CPython. My impression is that way fewer users compile themselves, and I don't have a sense of the profile or environments where they do.

[emmatyping]

My impression is that way fewer users compile themselves, and I don't have a sense of the profile or environments where they do.

I think there are a few use cases where users do build CPython from source: Gentoo, pyenv (which I think builds Python in many instances), embedders of Python on Linux, and if someone wants a version not packaged by their distro.

I think there are enough users who compile Python that it is a workflow we need to be cognizant of.

[emmatyping]

Coming back to this, I think choosing a relatively new MSRV is probably fine for now. It's easy to download a Rust toolchain, and distros that want to build CPython 3.16 with Rust support are going to be rolling releases or testing new releases, so their Rust toolchains should be relatively recent.

I do think Ed made a good point above

If you require your production MSRV for development (e.g. using rust-toolchain.toml file), you prevent people from leveraging new development-time features

• I also find it annoying when contributing to a project to suddenly pull in a new toolchain

So I think we should probably move from a toolchain file to the rust-version metadata. I also like the idea of linting with a newer Rust. Sanitizers will need to use nightly for now, and can likely track whatever newer stable version supports sanitizers when stabilized.

[emmatyping]

I think for now, let's choose a version and see how it works for us.

I propose we set a minimum of 1.95, and see if that introduces issues. The next step would be to make a PR and replace the toolchain file with a rust-version metadata field in Cargo.toml.