search

Qiskit / rustworkx

A high performance Python graph library implemented in Rust.
https://www.rustworkx.org
Apache License 2.0
1.11k stars 151 forks source link

Raise MSRV to 1.56 #716

Closed mtreinish closed 2 years ago

mtreinish commented 2 years ago

What is the expected enhancement?

Right now our MSRV for rustworkx is 1.48 to match what the latest rust version that Debian stable ships. This was originally done to support the piwheels build environment which installs rustc via debian packages. However this causes a lot of development friction as our upstream dependencies typically adopt newer MSRVs much faster than debian bumps their MSRV. It also blocks us from using newer rust language features. When weighing that against the raspberry pi user base via piwheels is very small (607 all time downloads compared to our monthly pypi download rate of ~150k) and the rustworkx wheels failed to build so there hasn't been any downloads of it ye I think we should just pick an MSRV that suits our development needs more than trying to maintain compatibility for an unsupported platform.

I'd like to propose we bump the MSRV to 1.56.1. This is the version that adds rust edition 2021 and I think will enable us to use the latest versions of most of our upstream dependencies (it's also the MSRV that qiskit-terra picked for similar reasons).

IvanIsCoding commented 2 years ago

I agree with bumping the Rust version.

I want to support the most platforms we possibly can (see #703 for example), but having this external constraint that we need to compile out of vanilla Debian is very restricting for keeping up with PyO3 and our other dependencies.

If piwheels had something like the custom builds like conda-forge does for us we could even contribute, but their build system is extremly unflexible. I'd rather build linux_armv6l and linux_armv7l wheels on our CI and publish them manually

mtreinish commented 2 years ago

Well Pyo3 has the same msrv following debian policy (at the time I was in favor of it and one of the proponents for defining a pyo3 msrv policy). The extra complexity for pyo3 is that it's now used by cryptography which adds a whole layer of scale for usage that we don't ever have to worry about (like debian depends on cryptography for distro tooling written in Python). But it's definitely been a huge pain for other dependencies. The big one in my mind is ndarray which we've been on a really old version for a long time