Kyle Benesch

> I was expecting macosx_13_0_x86_64 > > Now if I set MACOSX_DEPLOYMENT_TARGET=13.0 I see the reason ; it flags all my python extensions modules as incompatible (but not my c++...

How does one affect the `MACOSX_DEPLOYMENT_TARGET` or `MacOS.version` of a program built by brew? I'm not experienced with it and I don't have the platform to mess around with it.

> Is it true that compiling with macos-12.7 creates wheels that cannot run in macos-12.0 because of an incompatible libc++.1.0.dylib ? That's true by definition. The minor version increment indicates...

Rereading the posts on this issue seems to confirm my suspicions. It was an error to include the minor version number for the later versions of MacOS.

The 2nd version number is truncated in a similar way as the third version number is truncated in macOS releases before 11. At least that's how I see it. The...

I'm not a native Mac user. I need to know more about the nature of the minor version in macOS 11+ to have an opinion on it. If it's simply...

That's a pretty good example. In that case maybe a warning for when `MACOSX_DEPLOYMENT_TARGET` is not provided?

I expect `cibuildwheel` will set a reasonable `MACOSX_DEPLOYMENT_TARGET` which probably won't pass the check in `delocate-wheel` in all but the most ideal circumstances. This just means that setting up `cibuildwheel`...

If I recall correctly it was a safety check since I wasn't sure how to handle a situation where a library references an external dependency but that dependency already exists...

At the very least I could probably change this into a warning instead of an error.