I'm trying to use OCMock in a project.
The package product 'OCMock' cannot be used as a dependency of this target because it uses unsafe build flags.
Great. I saw somewhere that specifying a commit hash instead of a version is supposed to be an "escape hatch" for this error, but no, that doesn't work, at least not for Xcode projects.
What gives?
AFAIK, this is completely intentional.
The only workaround I'm aware of is to use a local dependency instead of a remote one (so, clone OCMock as a submodule and integrate it by path)
It's there for a reason, because a package dependency deep in your graph could include flags that allow it to overwrite files the build system has access to, or embed their contents in your binary to exfiltrate when you run it.
https://ocmock.org/ docs don't say anywhere that "swift package" is a supported installation method, which is interesting.
Yes, that is a good reason. There is no good reason to not have an escape hatch, some way to say, "get out of my way, I know what I'm doing!"
Heck, it could be a boot argument, or part of disabling SIP! There are boot arguments like amfi_get_out_of_my_way for this kind of thing, allowing self-signed code to run (if, say, you don't wanna pay Apple to write software for your own OS)
Cloning the repo locally just to do this crap is a disrespectful amount of hoops to jump through to get around this.
Yeah, I suppose not, but I've run into this with my own packages as well before.
Note that in Swift 6.2 we've opted to remove the restrictions around unsafe flags. See Pitch: Disable checks for unsafe flags in SwiftPM for the pitch thread.
I almost can’t believe my eyes—seriously? I could cry!
I’m running Xcode 16.2 at the moment so that’s probably why I didn’t notice. Although I wish the swift-tools-version didn’t matter… but I bet the few packages that use unsafe flags will quickly bump that version.
Thanks so much for letting me know about this, Jake!