Generalize detected FP environment handling on ARMv7#19157
Conversation
|
Gotta update the docs for the |
Signed-off-by: William Woodruff <william@astral.sh>
Signed-off-by: William Woodruff <william@astral.sh>
| // We currently assume hard-float in that case. | ||
| if matches!(arch.family(), Architecture::Arm(ArmArchitecture::Armv7)) | ||
| && matches!(env, Environment::Gnu | Environment::Musl) | ||
| { |
There was a problem hiding this comment.
Why do we want to assume hard-float in this case?
There was a problem hiding this comment.
That matches the previous behavior -- Gnu and Musl signal a FP detection failure and we only offer hard-float binaries for Ruff and uv anyways, so we assume that the user really does have hard-float support and send them a binary. I think that's pretty reasonable, since the number of soft-float ABI ARMv7 hosts out there (that are capable of running uv itself) should be pretty small.
The failure mode for that is that a user who is running a soft-float ABI will get a SIGILL or similar when they try to run the fetched binary. But that's what already happens in the (ARMv7, musl) scenario.
There was a problem hiding this comment.
(But note: we could change that into a warning or a hard failure here instead, and conservatively fail. No strong opinion from me!)
There was a problem hiding this comment.
I think we'd at least want to make the comment clear that we assume hard-float because that's the binary we provide. Unfortunately we do provide soft-float armv7 builds in python-build-standalone, so I don't think this is universally correct.
Can a hard-float host run a soft-float binary?
Why don't we do this when we handle the Err variant from the detection instead of here?
There was a problem hiding this comment.
Unfortunately we do provide soft-float armv7 builds in python-build-standalone, so I don't think this is universally correct.
Yep, but IIUC this pathway doesn't get used for PBS, only for the uv format and uv self update flows. I can update the comments to cover that nuance too.
Can a hard-float host run a soft-float binary?
I believe so -- my understanding is that eabihf is a superset of eabi, so any binary that targets EABI (with soft-float) will work on a hard-float host. But the performance will be terrible 🙂
Why don't we do this when we handle the
Errvariant from the detection instead of here?
I think we could, but it might also be a layering violation. Right now libc detection is shared across all three pathways (uv upgrade / uv format / PBS), and I think we want the PBS pathway to be able to make different decisions (since as you note there is a soft-float build available).
Another option there would be to turn FP detection errors into hard errors, rather than leaving it to each downstream layer to try and suss out an appropriate decision. I think that would be fine to do, although it'd be a blind change in terms of how many users are currently getting the right binary despite FP detection failure because we currently fall-through to hard-float on ARMv7.
There was a problem hiding this comment.
Ah I see we're just doing this in as_cargo_dist_triple.
I think my original request to update the comment is all I need then.
There was a problem hiding this comment.
I don't think we should fail if we can't read the procfs file to detect fp features. It seems unfixable for users.
There was a problem hiding this comment.
Yeah, makes sense. I suspect users will hit that semi-frequently in container environments (or in environments that do weird IDS things like blocking procfs reads).
There was a problem hiding this comment.
Can a hard-float host run a soft-float binary?
No, at least in the general case. Hard float (armhf) and soft float (armel) use different dynamic loaders (/lib/ld-linux.so.3 vs /lib/ld-linux-armhf.so.3) so a hard float distribution will not have the necessary loader (or dynamic libraries) to run a soft float binary.
Some/many distribution support multi-arch, so a soft-float (armel) loader and libraries can be installed allowing soft-float binaries to be run on a hard-float system but this is the exception and should not be expected.
Signed-off-by: William Woodruff <william@astral.sh>
This MR contains the following updates: | Package | Update | Change | |---|---|---| | [uv](https://github.com/astral-sh/uv) | patch | `0.11.7` → `0.11.11` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>astral-sh/uv (uv)</summary> ### [`v0.11.11`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#01111) [Compare Source](astral-sh/uv@0.11.10...0.11.11) Released on 2026-05-06. ##### Bug fixes - Accept legacy ID format from pre-0.11.9 cache entries ([#​19301](astral-sh/uv#19301)) ### [`v0.11.10`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#01110) [Compare Source](astral-sh/uv@0.11.9...0.11.10) Released on 2026-05-05. ##### Bug fixes - Allow pre-release Python requests with non-zero patch versions ([#​19286](astral-sh/uv#19286)) ### [`v0.11.9`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#0119) [Compare Source](astral-sh/uv@0.11.8...0.11.9) Released on 2026-05-04. This release includes a special release candidate for the next Python 3.14 patch release. Python 3.14 included a new garbage collection implementation, which reduced pause times but caused significant unexpected memory pressure in production environments. In 3.14.5 and 3.15, the previous garbage collection implementation will be restored. We would greatly appreciate if you tested the 3.14.5rc1 version included in this release. The stable version is expected to be released soon and any feedback on potential issues would be helpful to the Python development team. For more context, see the [announcement](https://discuss.python.org/t/reverting-the-incremental-gc-in-python-3-14-and-3-15/107014), [issue](python/cpython#148726), and [pull request](python/cpython#148720). Issues with the new release can be reported in the uv or CPython issue trackers. ##### Python - Upgrade PyPy to v7.3.22 - Add CPython 3.14.5rc1 - On macOS, CPython statically links `libpython` to match Linux ##### Enhancements - Omit compatible release desugaring for pre-release hints ([#​19267](astral-sh/uv#19267)) - Fix file locks on Android ([#​18323](astral-sh/uv#18323)) ##### Preview - `uv audit` add reporting for adverse project statuses ([#​19128](astral-sh/uv#19128)) ##### Bug fixes - Discover versioned Python executables when `requires-python` pins a version ([#​18700](astral-sh/uv#18700)) - Fix URL prefix matching to require path boundaries ([#​19154](astral-sh/uv#19154)) - Fix transitive Git path dependencies in lockfiles ([#​19269](astral-sh/uv#19269)) - Handle incorrect unlock error in `LockedFile::drop` on Wine ([#​19229](astral-sh/uv#19229)) - Prevent uninstalling site-packages for empty `top_level.txt` in `.egg-info` ([#​19114](astral-sh/uv#19114)) - Use symlinks instead of junctions on Wine ([#​19213](astral-sh/uv#19213)) - Fix floating-point environment handling on ARMv7 ([#​19157](astral-sh/uv#19157)) - Redact credentials from remote requirements URL in offline errors ([#​19216](astral-sh/uv#19216)) - Windows tramplolines no longer set `PYTHONHOME` and only set `__PYVENV_LAUNCHER__` for virtual environments ([#​19199](astral-sh/uv#19199)) ##### Documentation - Mark `--native-tls` and `UV_NATIVE_TLS` as deprecated ([#​18705](astral-sh/uv#18705)) - Re-add `pytorch-triton-rocm` to PyTorch ROCm docs ([#​19241](astral-sh/uv#19241)) - Tweak changelog entries for 0.11.8 ([#​19188](astral-sh/uv#19188)) - Add 'Exporting lockfiles' to the Concepts->Projects index ([#​19209](astral-sh/uv#19209)) - Clarify that `uv init` creates git files / folders in the projects guide ([#​19183](astral-sh/uv#19183)) ### [`v0.11.8`](https://github.com/astral-sh/uv/blob/HEAD/CHANGELOG.md#0118) [Compare Source](astral-sh/uv@0.11.7...0.11.8) Released on 2026-04-27. ##### Enhancements - Add `--python-downloads-json-url` to `python pin` ([#​19092](astral-sh/uv#19092)) - Fetch uv from Astral mirror during self-update ([#​18682](astral-sh/uv#18682)) - Support `pip uninstall -y` ([#​19082](astral-sh/uv#19082)) - Allow `exclude-newer` to be missing from the lockfile when `exclude-newer-span` is present ([#​19024](astral-sh/uv#19024)) - Only show the version number in `uv self version --short` ([#​19019](astral-sh/uv#19019)) - Silence warnings on empty `SSL_CERT_DIR` directory ([#​19018](astral-sh/uv#19018)) - Use a sentinel timestamp for relative `exclude-newer` and `exclude-newer-package` values in lockfiles ([#​19022](astral-sh/uv#19022), [#​19101](astral-sh/uv#19101)) ##### Configuration - Add `UV_PYTHON_NO_REGISTRY` ([#​19035](astral-sh/uv#19035)) - Add an environment variable for `UV_NO_PROJECT` ([#​19052](astral-sh/uv#19052)) - Expose `UV_PYTHON_SEARCH_PATH` for Python discovery `PATH` overrides ([#​19034](astral-sh/uv#19034)) ##### Bug fixes - Add `rust-toolchain.toml` to uv-build sdist ([#​19131](astral-sh/uv#19131)) - Ensure uv invocations of git do not inherit repository location environment variables ([#​19088](astral-sh/uv#19088)) - Redact pre-signed upload URLs in verbose output ([#​19146](astral-sh/uv#19146)) - Handle transitive URL dependencies in PEP 517 build requirements ([#​19076](astral-sh/uv#19076), [#​19086](astral-sh/uv#19086)) - Support `uv lock` on a `pyproject.toml` that only contains dependency-groups ([#​19087](astral-sh/uv#19087)) - Disable transparent Python upgrades in projects when a patch version is requested via `.python-version` ([#​19102](astral-sh/uv#19102)) - Fix Python variant tagging in the Windows registry ([#​19012](astral-sh/uv#19012)) - Ban external symlinks in `.tar.zst` wheels ([#​19144](astral-sh/uv#19144)) ##### Distributions - Remove deprecated license classifiers from uv-build and add Python 3.14 classifier ([#​19130](astral-sh/uv#19130)) ##### Documentation - Bump astral-sh/setup-uv version in docs ([#​19030](astral-sh/uv#19030)) - Update PyTorch documentation for PyTorch 2.11 ([#​19095](astral-sh/uv#19095)) </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box --- This MR has been generated by [Mend Renovate](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xNjguNSIsInVwZGF0ZWRJblZlciI6IjQzLjE2OC41IiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJSZW5vdmF0ZSBCb3QiLCJhdXRvbWF0aW9uOmJvdC1hdXRob3JlZCIsImRlcGVuZGVuY3ktdHlwZTo6cGF0Y2giXX0=-->
Summary
This is an attempt at fixing #19137. See #19139 (comment) for my understanding of the situation and motivation for this approach (versus the simpler approach in #19139).
TL;DR: we were unconditionally appending
eabihfto all libc variants when constructingcargo dist-style triplets. This was incorrect for a long time, but didn't surface on hot user paths until #18674 reused that pathway for uv's own self-upgrade logic. The fix is as simple as not doing that, except that we do want to do it in the bareGnuandMuslcases, since those signal FP detection errors (and we optimistically assume the user really has a hardfloat environment). So now we emit the appropriateMusleabi/Musleabihfvariants and specialize the append to just the FP detection failure cases for bothGnuandMuslexplicitly.Closes #19137. Closes #19139.
Test Plan
Added a unit test demonstrating the new
as_cargo_dist_triplebehavior.