Sorry if I have been unclear. I'm building a PyO3/maturin project throughciebuildwheel. My project depends on skia-safe. So ciebuildwheel calls maturin, maturin calls cargo, cargo runs the build.rs from skia-safe which in turn calls the above Python script as part of the skia build process. Is that the missing link? :)

It's not cibuildwheel's fault, but some libraries will not expect to run in environment where sys.platform in the default Python intepreter returns ios.

Thanks - that's helpful context.

From what I can make out, the problem lies around here - the build command is invoking the python that it has found in the environment; but cibuildwheel is providing the "fake" iOS python.

The current cross-platform environment for iOS doesn't provide a way to "turn off" the cross-platform features. To get the "actual" Python, you'd need to get prerequisites.locate_python3_cmd() to not return the venv's Python - but that's going to be difficult to do that many layers deep in cibuildwheel calls, as it's already going to be manipulating PATH to hide the system python. You might be able to hard code some options here if the target is iOS, but that won't really be a robust solution.

Alternatively, it looks like you might be able to circumvent the download process by putting the skia build into "offline" mode; I don't know how you activate that inside the skia build, but that might provide a window where you can explicitly download the binaries for the build platform and put them somewhere so that skia can invoke them, avoiding the need to autodetect the path for the downloads.

Another approach would be to modify the fetch-gn script so that sys.platform == "ios" is interpreted as a "darwin" set of downloads. That probably won't work if your build machine is x86_64... but from the look of it, that script likely won't work on x86_64 macOS builds, so maybe that's not a concern.

In the (hopefully not too distant) future, I'm hoping to update cibuildwheel to use xbuild - the implementation there does provide a way to "turn off" cross-platform tools, by exporting XBUILD_ENV=off in the environment. That would give you a way to get the build Python without the cross-platform patches.

It's not cibuildwheel's fault, but some libraries will not expect to run in environment where sys.platform in the default Python intepreter returns ios.

Responding to this one specifically - yes, that's true. And that means the code isn't iOS compatible.

However, the same would be true for any other new platform - if I release a new OS that reports sys.platform == "foobar", then the Python ecosystem as a whole needs to be updated to accept that "foobar" is a reasonable and expected response. That's the situation we're in right now with iOS, Android and Emscripten.

Those three platforms add an additional layer of complexity in that they are also cross-compiling platforms, which isn't a situation that Python has historically needed to deal with - and as a result, the ecosystem is needing to come to terms with what that means as well.

I'm not across the specifics, but I wonder if it would be useful for cibuildwheel to add a version of Python to PATH with the name build-python (and build-pip) so that tools can use them? At least then there's a way for build tools to use python if they choose to support cross-compilation?

Having a build-python et al is a technique I've seen used elsewhere (crossenv, does that, for example). However, it's difficult to set up with out a full "build" venv; the XBUILD_ENV=off environment variable option in xbuild is how I've been able to make the approach a lot more practical.