-
Notifications
You must be signed in to change notification settings - Fork 785
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
syn 2.0 and MSRV #3113
Comments
I was expecting us to bump our MSRV to 1.63 when Debian Bookworm becomes stable in "mid 2023" as per https://github.com/PyO3/pyo3/blob/main/Contributing.md#python-and-rust-version-support-policy |
Alpine 3.17 has 1.64 but RHEL 9 seems to carry 1.62, so we would actually end up with 1.62 instead of 1.63 following that policy. |
Based on our experience with /metrics for pyca/cryptography, I would advocate for a slightly smaller jump. Based on our metrics, our plan is to do 1.56.0 as MSRV for our next release, and then 1.60 as our expected (subject to change) MSRV. |
Out of curiosity and to understand if our policy needs to be amended: Do your metrics include any indication of what users in the 1.56 to 1.61 bracket are running on or how they installed Rust? |
We use metrics from PyPI, so we hvae rustc version, OS, and other metdata. Here's the script I used to compute the data for us:
(Note that the BigQuery auth might be broken ATM? It stopped working a few weeks ago, so I don't have more recent metrics) Here's recent data on what OS+rustc combos are most frequently in the "has 1.56 but doesn't have 1.60" bucket: |
Interesting, so mostly outdated Alpine versions. So glad everyone keeps their container image builds fresh as daisies... |
It likely reflects that musllinux wheel support requires a newer pip, so those users also have an older pip. |
Sorry for the slow reply here on my part. I think the aging MSRV in PyO3 is probably slowing us down more than continuing to support Python 3.7 is. I also had the impression that Python 3.7 was still a significant proportion of downloads, e.g. about a third of recent I was considering if we should propose keeping 3.7 support until the end of the year or even longer, and bumping MSRV sooner (maybe even as part of 0.19). @alex I'd be interested to hear whether you think that would be beneficial for cryptography. |
To avoid leaving Debian users behind, I think we should at least wait with any MSRV increase until Debian Bookworm releases, and then we just need a decision whether we want to go straight to 1.62 or have a period of support with 1.56 first. |
Is there something in between 1.56 and 1.62 that we want? The main things that we want are below that, I think:
|
Do you have anything specific in mind w.r.t. slowing us do? Keeping our Otherwise, I am not sure it is really slowing us down. It does prevent certain simplifications and prevents some API improvements, but we have workarounds for example for the points @mejrs lists in place. Is there some place where lack of language (or standard library) features is really blocking us? Compared to say plain lack of time on our part? (Having to build both syn 1.0 and 2.0 in a single project is not nice, but it also not the end of the world IMHO.) |
I also think we should start with 1.56 and only bump to 1.62 if we actually have a situation where we want some later feature. |
I do think the 1.48 msrv is slowing/limiting us. We currently use a build script and conditional compilation to work around these, those have a bunch of downsides:
|
While I mostly agree with the assessment, it is the conclusion I am sceptical about: All of this applies to code bases that are frequently modified or see sweeping changes. I think that is unfortunately not the case for PyO3 at the moment. And I also do not think that removing those costs would change this meaningfully. Then again, we should not have even potential road blocks for no reason. But in this case, e.g. the Debian-oriented MSRV policy really is a feature in itself which currently costs us very little because the workarounds while ugly have been written and are not frequently modified. |
I have written code using manuallydrop and transmutes to get around not being able to iterate by-value over an array. I'd love to delete that code. |
@davidhewitt from our perspective, keeping Python 3.7 for a while (as you note, it's still widely used, we're only just removing 3.6 now) and raising the MSRV to 1.56 is optimal for us. This keeps support for things that are widely used, but let's us remove our usage of syn 1.0 (and it sounds like it allows some cleanups internal to pyo3 as well). If there's ways we can be helpful on these fronts, we're happy to. The period during which we supported 3.6, but pyo3 didn't, was pretty painful. Going forward we'd rather help out upstream if you're amenable. |
A couple of Rust releases contain some potential improvements:
That said, I think we're all converging on a 1.56 version bump once Debian bookworm releases, and then we can revisit later.
The two main drawbacks to supporting older Python versions in my opinion are:
The code in I think for now we're not feeling an immediate need to drop 3.7, however if we did, I think we'd be open to accepting bugfixes to the last PyO3 version which supported 3.7. @alex are there particular pain points which you hit? I recall the PyPy support, not sure what else you encountered. |
During the period where we were pinned to an older pyo3 version there were two pain points:
|
FYI, I managed to fix our Rust versions infra. Here's the numbers for the last 30 days, for version 40 of cryptography (MSRV of 1.48). For each version, the % is the % of downloads, with Rust version info, that have a rustc >= to that version.
|
👋
Right now, for pyca/cryptography, we're in an awkward space where half our dependencies use syn 2.0, and half use 1.0 (including pyo3). This is unfortunate from a compilation time perspective. The reason not to upgrade, and presumably why pyo3 hasn't, is that syn 2.0 raises their MSRV to 1.56.
I wanted to start a conversation on at what point it would make sense to raise pyo3's MSRV, and thus be able to use syn 2.0?
For pyca/cryptography, our upcoming release will raise our own MSRV from 1.48 to 1.56. You can see some of the data/reasoning behind this here: pyca/cryptography#7172, pyca/cryptography#8195, and pyca/cryptography#8587
The text was updated successfully, but these errors were encountered: