search

astral-sh / uv

An extremely fast Python package and project manager, written in Rust.
https://docs.astral.sh/uv
Apache License 2.0
20.49k stars 605 forks source link

Regression on tolerance for older Pythons #7418

Open garthk opened 5 days ago

garthk commented 5 days ago

Having only just recently improved uv's tolerance for Python 3.6 in #6996 merged @charliermarsh 2024-09-04, I'm dismayed to have the rug pulled out by #7266 merged @zanieb 2024-09-11.

As I've said before: while I appreciate the Python team no longer support Python 3.6, RedHat-style Linux distributions will support Python 3.6 in their/usr/libexec/platform-python until releasever 8 expires in 2029.

It strikes me as off brand for Astral to provide Python programmers with excellent tooling, except for those Python programmers, over there. (They're an "edge case", if you know what I mean. Cough.) If they'd personally earned a disregard bordering on spite, maybe, but not if they're helping? #6996 for example fixes the problem underlying #3371, which prompted this defensive work in get_operating_system_and_architecture.

I'm not asking for uv to provide a managed Python 3.6, but would appreciate a fix starting with a unit test ensuring --python=3.6 works if the following are all true:

notatallshaw commented 4 days ago

Some thoughts on having worked a lot with RHEL and legacy versions of software (and just being an outside observer here, I have no connection to Astral):

My understanding is the Python distro that RedHat supports only supports installing 3rd party libraries via RedHat, e.g. yum install python3-requests, if you're using pip or uv to instal you won't get RedHat support, and if you don't care about RedHat support why not upgrade your Python?

RHEL often supports things long past the unpaid support for an open source product ends, e.g. Python 2 support in RHEL ended just this year. If you would like a similar support that RHEL provides, perhaps consider emailing Astral and see if you can come to a paid service arrangenent like Red Hat does with it's customers?

zanieb commented 4 days ago

Sorry about that. https://github.com/astral-sh/uv/pull/7266 was fixing a clear oversight, in which we applied the Python version restriction on a subset of platforms. I'm fine with not erroring if we query a Python 3.6 interpreter, I'm not sure why we need that in the first place cc @konstin. The simple fix here may just be to lower that to <3.6 since we know the interpreter query script works with 3.6.

I don't have qualms with some form of 3.6 support if we're not spending a significant amount of time maintaining it.

konstin commented 4 days ago

That checks catches cases where machines have ancient versions of Python installed which would subsequently error in our discovery script and break discovery. If we want to allow Python 3.6, we need to have a platform check for 3.6 to ensure the script doesn't fail on those versions when evolving the discovery scripts, regressing for users that want to skip EOL versions.

charliermarsh commented 4 days ago

My only comment here is that if we're going to offer even "informal" support for this, we need a system test for it. Otherwise, it'll keep breaking. So that would be a welcome contribution (even if it's failing for now).

zanieb commented 4 days ago

I believe now if the query script fails we always skip the interpreter so I don't think that's as big of a deal as it was before. It's mostly about messaging around the failure of the query script, which I think is a tracing log anyway.

garthk commented 2 days ago

My understanding is the Python distro that RedHat supports only supports installing 3rd party libraries via yum install

@notatallshaw Fedora et al prefer any package shared across the system to use their packaging system. It's a plain Python distribution, though. You develop your Python package like any other: it's only after you build the wheel that anything changes.

Side note: Ruff's flake8-tidy-imports is a great way to make sure you don't use API surface added between the version of a package available as an RPM and the version that dropped support for your Python.

[tool.ruff.lint.flake8-tidy-imports.banned-api]
"re.Match".msg = "from typing import Match"
"re.Pattern".msg = "from typing import Pattern"
"typing_extensions.NotRequired".msg = "python3-typing-extensions-3.7.4.3-2"
"typing_extensions.OrderedDict".msg = "python3-typing-extensions-3.7.4.3-2"
"typing_extensions.override".msg = "python3-typing-extensions-3.7.4.3-2"
"typing_extensions.ParamSpec".msg = "python3-typing-extensions-3.7.4.3-2"
"typing_extensions.ReadOnly".msg = "python3-typing-extensions-3.7.4.3-2"
"typing_extensions.Required".msg = "python3-typing-extensions-3.7.4.3-2"
"typing_extensions.Self".msg = "python3-typing-extensions-3.7.4.3-2"

While we're developing a Python package with all those arms tied behind our backs, it's the same as you're used to. We take our deps and dev-deps from PyPi while we're developing, re-testing against the deps' RPMs before we pack our own.

If I wanted you to work, I'd certainly expect to pay for it somehow, but I don't want your work. Kinda the opposite, really. If you're aware 3.6 matters to your users and customers, you won't break it, you won't be asked to fix it, and you won't risk tarnishing your brand in an attempt to justify why breaking it was fine actually.

Sorry about that. […] I'm not sure why we need that in the first place.

Thanks, @zanieb. #3371 reports a confusing error caused by the info script breaking on Python 3.6. #3398 delivers a less confusing error message by gating the version on Linux. #6996 fixes the info script so it works on Python 3.6. #7266 applies #3398's version gate to other platforms.

I should emphasise #3398 and #7266 were good calls given the information on hand at the time. I wish I had a time machine, but only so I could tell #6996 me to look wider.

I don't have qualms with some form of 3.6 support if we're not spending a significant amount of time maintaining it.

Yeah, nah, any load should be borne by those of us that need it. This week is a wreck, but perhaps next week I'll file a PR to relax the gate and add that test.

If we want to allow Python 3.6, we need to have a platform check for 3.6 to ensure the script doesn't fail on those versions when evolving the discovery script.

Quite true, @konstin. I think I remember seeing them in your PRs? I'll check.

If we're going to offer even "informal" support for this, we need a system test for it.

I love "informal", @charliermarsh: it's appropriate, and gentler than my "tolerate". Very on brand.

Would the test I described in my top post count as a "system test", or is there more you'd want to see in the PR?

notatallshaw commented 2 days ago

Kinda the opposite, really. If you're aware 3.6 matters to your users and customers, you won't break it, you won't be asked to fix it, and you won't risk tarnishing your brand in an attempt to justify why breaking it was fine actually.

Everything has a cost associated with it, adding 3.6 to the test matrix costs real money to a CI bill, and if it breaks for 3.6 only that costs real money in developer time.

At some point you have to decide when something is no longer worth supporting, most of the Python ecosystem has dropped support for Python 3.6 and 3.7, and numpy stack has dropped support for Python 3.8 and 3.9.

Astral may be happy to support 3.6 because the calculus makes sense to them, but it is a calculus, not a free ride, so as someone who supports and maintains OSS it's a bit frustrating to hear users who provide no support throw phrases around like "tarnishing your brand".