Xcode 16 SPM integration intermitently breaks with xctest-dynamic-overlay redirect

[NachoSoto]

See also #91.

Our project depends on this library, plus a few others from pointfreeco that also depend on xctest-dynamic-overlay.
Very frequently with Xcode 16.0 the SPM dependency graph gets in a broken state requiring a whole wipe of derived data:

github.com: https://github.com/pointfreeco/xctest-dynamic-overlay.git: The repository could not be found. Make sure a valid repository exists at the specified location and try again.

I think migrating all your libraries to point to the new swift-issue-reporting would fix this.

[NachoSoto]

Also pointing to swift-issue-reporting while using other dependencies that rely on xctest-dynamic-overlay doesn't work either:

multiple similar targets 'IssueReporting', 'IssueReportingTestSupport', 'XCTestDynamicOverlay' appear in package 'swift-issue-reporting' and 'xctest-dynamic-overlay', this may indicate that the two packages are the same and can be de-duplicated by using mirrors. if they are not duplicate consider using the moduleAliases parameter in manifest to provide unique names

[stephencelis]

@NachoSoto We unfortunately discovered that SPM packages don't fully support redirects in this fashion after releasing the update. While the most common case worked, there were many package graph edge cases that we needed to account for. We have encountered the resolution bug you refer to above, though luckily it's intermittent and can usually be resolved with a derived data purge, as annoying as it is.

At the core of it, SPM does not honor package renames and only seems to fully support organization renames. As such we plan on doing what we did with swiftui-navigation's migration to swift-navigation, which is to ship swift-issue-reporting as a new library with effectively a 2.0 starting point and keep XCTestDynamicOverlay in an older xctest-dynamic-overlay repo/package. We plan on doing this in the near future, but it is a delicate procedure and we don't want to break folks downstream, so we need to think through all the scenarios and make sure we're accounting for them.

I'll leave this issue open to track the migration, thanks!

[NachoSoto]

I appreciate the quick response. It's unfortunate as SPM's Xcode integration seems to have been unmaintained for years now.

A full derived data purge is a huge productivity kill for any large codebase though, so I hope you consider doing this migration in the shorter term, especially considering that this seems to be getting even worse on Xcode 16.1.