KNOWN_ARCHITECTURES causes test failures on unknown machines

[thesamesam]

In Gentoo, we saw discovery tests failing (https://bugs.gentoo.org/971943) because the running architecture wasn't present in KNOWN_ARCHITECTURES. Requiring whitelisting of every platform CPython runs on is already quite unfortunate, but..

KNOWN_ARCHITECTURES was made part of public API for tox-dev/tox#3903 (discovery side: #56, 38eac12). This means we also can't just patch it downstream either.

The failure looks like:

 _______________________________________________ test_py_info_machine_property _______________________________________________
[gw0] linux -- Python 3.13.12 /var/tmp/portage/dev-python/python-discovery-1.2.1/work/python_discovery-1.2.1-python3_13/install/usr/bin/python3.13

     def test_py_info_machine_property() -> None:
         machine = CURRENT.machine
         assert machine is not None
         assert isinstance(machine, str)
         assert len(machine) > 0
 >       assert machine in KNOWN_ARCHITECTURES, f"unexpected machine value: {machine}"
 E       AssertionError: unexpected machine value: alpha
 E       assert 'alpha' in frozenset({'ppc64', 'riscv64', 'loongarch64', 'i686', 'x86_64', 'ppc64le', 'x86', 'arm64', 's390x'}
 )
 
 machine    = 'alpha'
 
 tests/py_info/test_py_info.py:341: AssertionError

Can you please reconsider this approach? The status quo means we'll need to manually add various arches and then wait for a new discovery release for tox.

[mgorny]

And just to be clear, the complete list will be very long, since for example on ARM machines you'll have to cover full specs like armv8l.

[gaborbernat]

Can you please reconsider this approach? The status quo means we'll need to manually add various arches and then wait for a new discovery release for tox.

Is that that bad? I don't expect us to be needing to extend this list that often. That being said, we definitely should do a better job at having a more exhaustive list, or perhaps just having more of a same fallback in case the current platform doesn't match what we already defined.

cc @rahuldevikar

And just to be clear, the complete list will be very long, since for example on ARM machines you'll have to cover full specs like armv8l.

I see a world where we have some kind of regular expression matching rather than just a direct, explicit list, though, then again, how well known this is up front, I haven't looked into that deep.

[rahuldevikar]

I see, I think tox doesn't need to know all possible architectures — it only needs to know the current machine's architecture and whether a given factor matches it. What we can do here is Remove KNOWN_ARCHITECTURES and expose normalize_isa() as public API instead. Tox compares each env factor against the current machine's ISA at runtime using normalize_isa(factor) == machine_isa. This way it works on any platform with zero maintenance. Solves the cross-arch collision bug tox-dev/tox#3917 ISA only injected into factor set when the env name contains a matching arch factor. No allowlist to maintain.

The downside is a breaking change for any consumer that imports KNOWN_ARCHITECTURES.

[mgorny]

https://stackoverflow.com/questions/45125516/possible-values-for-uname-m gives some idea how complex the problem is (and IIUC the list in https://stackoverflow.com/a/78630608 is not complete).

[gaborbernat]

What we can do here is Remove KNOWN_ARCHITECTURES and expose normalize_isa() as public API instead

Let's do this.

[thesamesam]

Thank you!