pointfreeco / swift-issue-reporting

Report issues in your application and library code as Xcode runtime warnings, breakpoints, assertions, and do so in a testable manner.
https://www.pointfree.co
MIT License
391 stars 64 forks source link

xctest-dynamic-overlay dependency URL is redirecting to https://github.com/pointfreeco/swift-issue-reporting #91

Closed joelCHonor closed 3 months ago

joelCHonor commented 3 months ago

Hi guys, we started to have issues some minutes ago with our builds. In our Jenkins CI, Xcode is trying to load dependency for 'xctest-dynamic-overlay', but is loading instead 'swift-issue-reporting' package. When I navigate from my browser to http://github.com/pointfreeco/xctest-dynamic-overlay, it automatically redirects to https://github.com/pointfreeco/swift-issue-reporting. Then I see the 'swift-issue-reporting' package added twice to our Project, and it doesn't compile We are using Xcode 15.3 and TCA library: 1.11.0 Did any change happens recently on your repos structure?

stephencelis commented 3 months ago

Hi @joelCHonor. I believe you need to update to TCA 1.12.0 or you need to pin to lower versions of its dependencies.

joelCHonor commented 3 months ago

I can try that, still not a solution I'm comfortable with as we chose 1.11.0 exact version because it has the things we needed, and we tested our app agains it. If I move to 1.12.0, will need to run a lot of tests to check there is no regression, the same for a lower version. How come you stopped to support a version some people was using?

stephencelis commented 3 months ago

@joelCHonor We didn't stop supporting a version that people are using, but we did release a new version of a dependency that requires upgrading to use.

While you have pinned your TCA dependency, you have not pinned its dependencies, and it sounds like your CI is not using a Package.resolved file to ensure that it doesn't pick up random new versions. Generally what you do in Swift is check in your Package.resolved file to ensure that CI doesn't randomly pick up new versions of your dependencies, but you can also explicitly pin sub-dependencies to exact versions and you would have also avoided this issue.

joelCHonor commented 3 months ago

Yes I understand that, but if a package URL in older versions of TCA package looks for 'https://github.com/pointfreeco/xctest-dynamic-overlay' and the package doesn't exist anymore (as it was replaced by issue-reporting), even If I use specific version of XCtest-dyn... that won't work anymore. You said you didn't stop supporting a version, but from your statement, we can't use '1.11.0' anymore. That for me is forcing us to switch to a different version of TCA (something that in my company we do carefully)

stephencelis commented 3 months ago

@joelCHonor SwiftPM supports redirects, and https://github.com/pointfreeco/xctest-dynamic-overlay redirects to https://github.com/pointfreeco/swift-issue-reporting. Existing pinned dependencies will continue to work just fine, you just need to lock down your repo's dependencies by checking in your Package.resolved file, or you need to start pinning all your dependencies and dependencies' dependencies explicitly.

joelCHonor commented 3 months ago

ok, I see. I will try then the solution. Thanks for your help on this.

joelCHonor commented 3 months ago

@stephencelis By using the pinned dependencies, I was able to keep current TCA version. Thanks for the information you provided. Not sure if you want to keep the issue opened for reference in case more people is experiencing the same issue. If not, go ahead and close it. Also, I think this could be important information you can add in TCA's Readme file, because I know many teams maybe don't have locked references and changes like this one you did could affect them

stephencelis commented 3 months ago

@joelCHonor We'll close this but reference it if it comes up again. We're not sure we can do this in all our READMEs as the migration is transitional, and if folks are using Package.resolved then it should ideally work seamlessly. We do our best to work with the tools we have, and SwiftPM's migration story for package renames isn't perfect, but it's good that it works at all :smile: