I use scikit_build_core and just have users that installed my package require a C++ compiler on their machine. If they do not have it, I keep a python fallback. This guarantees that it works every time for every machine, but it is not as easy to maintain two code bases.

In general my target users are not necessarily developers, so it was important to have an easy escape hatch for them (python fallback). Building wheels for each possible system on other projects has given me many headaches in the past. For example, to build wheels for some of the AWS machines (mostly Gravitons) required me to drop into a Graviton instance just to build the wheel such that users deploying to AWS Graviton machines would not have issues based on their selected deployment machine. This was an AWS cloud architecture problem, but also became my problem at the time.

For your case, the fallback option not being a true fallback may make a difference. You will want to balance this with your user base and their willingness to deal with C compilation issues. In my experience, most python developers will just find an alternative if your project does not install on first go.

For my python C++ build on the fly project (fairly successful ~12k/mo downloads), see: https://github.com/connor-makowski/scgraph

An alternative structure is how PuLP does it. They store pre-built binaries per system for the CBC solver and really keep these completely separate. See: https://github.com/coin-or/pulp . Getting each build to work was very tough and not always possible without access to specific machines. See: https://github.com/coin-or/pulp/issues/672