Detect x86_64 microarchitecture variant automatically

[zanieb]

e.g., on my test machine

❯ cargo run -- python install 3.12
Installed Python 3.12.8 in 3.65s
 + cpython-3.12.8-linux-x86_64_v3-gnu

Note this is split into two commits:

• c0f146c: which adds detection
• 5d78bf2: which improves behaviors and compatibility between architecture variants

[notatallshaw-gts]

While mostly I would want uv to automatically detect which microarchitecture variant to grab, I have a concern here related to docker images, specifically if uv is used to install Python in the dockerfile, what happens when the build machine and execution machine support different instruction sets?

[zanieb]

I have a concern here related to docker images, specifically if uv is used to install Python in the dockerfile, what happens when the build machine and execution machine support different instruction sets?

I think it's fair to say the build machine will need to be on the same (or an older) microarchitecture than your execution machine. Do you think that's unreasonable?

[notatallshaw-gts]

I think it's fair to say the build machine will need to be on the same (or an older) microarchitecture than your execution machine. Do you think that's unreasonable?

Only in the sense it's not something I have to think about right now, and without being familiar with this I'm not sure it would be easy to diagnose when a failure happened?

[zanieb]

Only in the sense it's not something I have to think about right now, and without being familiar with this I'm not sure it would be easy to diagnose when a failure happened?

Yeah the interpreter would probably just crash at runtime, or, if you use uv as your entry point, it would be "missing"

[notatallshaw-gts]

Maybe this is already an issue with other tools that are installed into docker images, and it's not that common to face, and people who do face this problem are familiar with the symptom and cause. I just never thought about it before now.

[danielhollas]

Maybe this is already an issue with other tools that are installed into docker images, and it's not that common to face, and people who do face this problem are familiar with the symptom and cause. I just never thought about it before now.

I don't think this is a common issue right now, and you raised a very valid concern. For pre-built binary artifacts, for example most Linux distros AFAIK use conservative microarchitecture and don't do any runtime detection.

There has been some discussion about this in Fedora but the proposal to bump microarchutecture has been withdrawn?

https://discussion.fedoraproject.org/t/will-future-releases-require-x86-64-v3/131200/6

[drmikehenry]

Assuming this feature is eventually implemented, it would be helpful to have a way to disable CPU microarchitecture detection to retain the current behavior that v1 is used by default. This would make it possible for folks who are mirroring python-build-standalone to continue to mirror only the v1 binaries rather than the whole set of microarchitectures, reducing both space and time requirements for mirroring. Developers might also prefer to use the same Python executables across an entire team for consistency.

[zanieb]

@drmikehenry thanks for the feedback!