Kyle Benesch

> Another option would be to rename the command to `delocate-fuse-universal` and have `delocate-fuse` raise an error pointing to `delocate -fuse-universal`. At least that way no-one will be confused when...

> What if we add a flag `--overwrite/--no-overwrite`. The default when neither is given, **for now**, being `--overwrite`. But in this case, we raise the informative error matthew-brett would like...

> And what I believe your position is, which is we should retag by default, not because it is a good idea, but because doing anything else is incorrect and...

> I don't understand why you feel a new command is better than requiring a new flag on `delocate-fuse`. I don't have any preference on the name but something like:...

Can you try setting the environment variable `MACOSX_DEPLOYMENT_TARGET=11.0` (set it to whichever version you're trying to target) before running `delocate-wheel`?

Which dependencies are forcing 13.6? If those are built locally then maybe set `MACOSX_DEPLOYMENT_TARGET=11.0` for the entire workflow.

I'll clarify that Delocate 0.11.0 has PR #198 applied which is the cause of the "error". For other devs, this was able to reveal compatibility issues unknown before the release...

Which tool/command gives a list of compatible tags?

If the wheels fixed by Decloate in `macos-14-large` output with a later version of MacOS but still work on earlier versions then the libraries provided by that runner have an...

> same issue here, my wheel gets renamed with an unsupported tag: macosx_13_6_x86_64 What was the tag you expected? And did you set `MACOSX_DEPLOYMENT_TARGET`?