account for new error message from lipo

[glyph]

fixes #279

Pull Request Checklist

• Read and follow the CONTRIBUTING.md guide
• Mentioned relevant issues
• Append public facing changes to Changelog.md
• Ensure new features are covered by tests
• Ensure fixes are verified by tests

[HexDecimal]

Adding the affected runner should be enough for regression testing, but you'd have to show me that the workflow reproduces the error in the first place.

You'll also need to note what's been fixed in the changelog.

[HexDecimal]

I worry about changing this to search. Maybe edit the expression to account for the match being towards the end.

[HexDecimal]

Why was \n$ removed from the end here?

[glyph]

Given that the putative error here is "the error message was far too strict and an upgraded compiler breaks it", I felt like it made sense to loosen the matching strategy given that it seems unlikely to see this exact message even with a .search(). If you'd prefer I can definitely be stricter about it though.

[HexDecimal]

Given that the putative error here is "the error message was far too strict and an upgraded compiler breaks it"

This would be justified if the minor change was required for this fix, but in this case lipo's output was changed in a way that requires a whole new expression to parse. You should try your best not to tamper with the original expression unless you have a more well thought out refactor in mind.

[glyph]

This would be justified if the minor change was required for this fix, but in this case lipo's output was changed in a way that requires a whole new expression to parse. You should try your best not to tamper with the original expression unless you have a more well thought out refactor in mind.

Fair enough, I'll try to mirror the previous strictness.

[glyph]

Adding the affected runner should be enough for regression testing, but you'd have to show me that the workflow reproduces the error in the first place.

There's a reproducer on the issue, does it not work for you?

[HexDecimal]

There's a reproducer on the issue, does it not work for you?

Reproducing the wheel isn't necessary since this issue applies to all wheels. More specifically, Delocate runs lipo on all files and uses the output to tell if a file was a regular-file rather than a library, but the error message from lipo for non-library files has been changed in the most recent version.

I'm inexperienced with MacOS so it's unclear to me if lipo depends on the MacOS version or the installed XCode version.

The new runners from GitHub are called macos-26-intel and xcode-27. Adding these to the isolated_tests matrix should reproduce the error but I can't be sure. I can try this myself or I can trust you to do it.

[glyph]

I'm inexperienced with MacOS so it's unclear to me if lipo depends on the MacOS version or the installed XCode version.

I'm pretty sure it's the latter but sometimes I am surprised by details of this interaction.