braintree_ios: No such module 'PPRiskMagnes', continued
Integration Details (please complete the following information):
- Braintree SDK Version: 5.4.3
- Environment: Production
- iOS Version: N/A (problem occurs at build time)
- Xcode Version: Xcode 12.5.1
- Device: N/A (problem occurs at build time)
- Integration type & version: Swift Package Manager (version included w/ Xcode 12.5.1)
Describe the bug First, I’ll acknowledge that this bug has been discussed a handful of times and has been marked as resolved a handful of times as well, but this still seems to be happening. Related issues include but may not be limited to the following:
When building the app, occasionally within Xcode on our machines (this occurs to my team as well, not just me) but more commonly when running in CI, the build will fail with the following error:
/Users/runner/Library/Developer/Xcode/DerivedData/SCHEME-bdxyuxwdpsyvykcozvxottrpexnb/SourcePackages/checkouts/braintree_ios/Sources/PayPalDataCollector/Public/PayPalDataCollector/PPDataCollector.swift:1:8: no such module 'PPRiskMagnes'
referencing the line in PPDataCollector - import PPRiskMagnes.
To Reproduce Reproducing this issue is kind of a funny situation. It’s “hard to reproduce” because I cannot pinpoint the issue to any specific cause, but it “reproduces itself” frequently enough to be a pretty regular inconvenience in our build process. Worth mentioning as well, because of the way that macOS minutes are billed on GitHub Actions, these failed builds actually end up wasting money. When this fails in a CI job, I am normally able to circumvent the issue by re-running the job and hoping that the issue doesn’t occur on that build. That said, I still do not think the presence of a semi-workaround is reason to consider this a non-issue.
As stated before, this occurs periodically when building. The move to Xcode 12.5.x and BT 5.4.3 as described in your docs mitigated the issue, but the issue still persists. Prior to updating our GitHub Actions to macOS 11 (enabling us to use Xcode 12.5), the last working version of Braintree I had been using for quite some time was v5.2.0.
Some additional information about the latest failure I encountered:
GitHub Actions Environment Info
1 Current runner version: '2.280.3'
2 Operating System
3 macOS
4 11.5.2
5 20G95
6 Virtual Environment
7 Environment: macos-11
8 Version: 20210831.3
9 Included Software: https://github.com/actions/virtual-environments/blob/macOS-11/20210831.3/images/macos/macos-11-Readme.md
10 Image Release: https://github.com/actions/virtual-environments/releases/tag/macOS-11%2F20210831.3
Build Execution Outtakes (Abbreviated)
xcodebuild -resolvePackageDependencies -scheme SCHEME -project ./PROJECT.xcodeproj
/Applications/Xcode_12.5.1.app/Contents/Developer/usr/bin/xcodebuild -resolvePackageDependencies -scheme SCHEME -project ./PROJECT.xcodeproj
...
Cloning local copy of package ‘braintree_ios’
Checking out 5.4.3 of package ‘braintree_ios’
...
Linking BraintreeCore.o
Compiling PPDataCollector.swift
❌ /Users/runner/Library/Developer/Xcode/DerivedData/SCHEME-bdxyuxwdpsyvykcozvxottrpexnb/SourcePackages/checkouts/braintree_ios/Sources/PayPalDataCollector/Public/PayPalDataCollector/PPDataCollector.swift:1:8: no such module 'PPRiskMagnes'
...
Testing failed:
Command CompileSwift failed with a nonzero exit code
No such module 'PPRiskMagnes'
Testing cancelled because the build failed.
Expected behavior Build does not fail due to missing module.
Hopefully the information provided can be some sort of help to the team in triaging and resolving the issue at hand. I am happy to provide as much information as I am able to, though what I have provided in this issue is as much as I know.
Thank you!
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 51 (15 by maintainers)
👋 Hi everyone. This is more of an exploratory comment/question - The
braintree_iosSDK has two other frameworks with binary dependencies. I am curious to gauge who in this group uses these other frameworks / if you have every seen this same issue with another Braintree framework.React to this comment with: ❤️ if you use
BraintreeThreeDSecure🚀 if you useBraintreeDataCollector😄 if you use none of the above, but usePayPalDataCollectorThank you all for testing! This has been released in version 5.6.3.
Any update on this? @scannillo
Hello @simonpierreroy (and everyone else following this thread) - we’ve put up a test branch for this named
update-package-dependenciesin PR #785 that pulls in the changes recommended by you, Simon.Our CI is passing so the other package managers seem to be happy with this change. As we have not been able to replicate this error, would anyone (or everyone) that has run into this issue mind pulling in the branch and testing and letting us know the results?
If this does work, we can get a release out with this change, if it does not resolve the issue, we’d be more than happy to continue troubleshooting.
👋 Hey all - I am going to close this issue as several folks have indicated the fix in version 5.6.3 is resolving the initial reported issue. That said, if this creeps back up, please feel free to respond here and we’d be happy to reopen the issue and troubleshoot further. 🚀
@srikanth-vm - we hope to have a release with this change out this week, our UI tests are failing due to a backend service, so once that is resolved and our build is 🟢 we will merge the change and cut a release. I’ll update the thread here as soon as it’s released for everyone to pick up.
I’m seeing this as well with every build, including with the latest
5.5.0release. Is there any known version of Braintree that works reliably with Swift Package Manager?+1 to this. Happening here as well and it’s really frustrating.
Xcode 13.1 BraintreeDropIn 9.20 (exact version) Forcing Braintree to be 5.4.4 and not letting BraintreeDropIn resolve it by itself (exact version)
I may revert Braintree to be used through Cocoapods. SPM has been around for a while and it’s our preferred option though.
Thanks for testing @DrBeak1 and @eseay! We’ll update you all here once we’ve cut a release with this change included.
@eseay it will probably take make weeks before I can test… I will try definitely at some point. But I think there is no harm in merging this fix since it only add correctness to the swift package definition. Maybe other folks that had issues can try and report back.
That is normal! The package file has not been fixed for 13.2! https://github.com/braintree/braintree_ios/issues/735#issuecomment-993967490 c.c. @agarcia-wish @scannillo. Need to add back the binary dependencies entry for each module that use a binary !
This is normal, due to the bug mentioned here https://github.com/braintree/braintree_ios/issues/735#issuecomment-947787052 , if your derived data is warm up, or if your machine compute a different build graph (parallelism), it may or may not fail. Plus, I think the latest version does not link properly the binary dependency on the swiftpm file. (Even if it will fail, dur the Apple Bug mentioned above)
@scannillo Not yet, since FB77465707 in the Xcode 13 release notes acknowledged that any swiftPM target that depends on a XCFramework can break (since Xcode 12.0), and there is no work around possible! So by moving targets around, it may work by chance for some folks, but in our code base it will alway fail since we have a big build graph were the issue can be reproduced consistently, even with internal packages. I removed all usage of XCFrameworks in swiftpm targets in our codebase. For braintree, I built the full graph of dependencies as XCFrameworks and linked those to our main app directly, removing your swiftpm package. I have no hope that this 1 year old bug will be fixed anytime soon, but still I hope I am wrong. For now, I used swiftPM a lot in our code base, but banned XCframework dependencies in a swiftpm target (your exact use case). We can only use xcframeworks if linked to any app (even if distributed with swiftpm, but not used in a swiftpm target). Thank you for following up 😃 Please let me known if you will offer a version that does not require any pre build binary, or a version that pre-build binaries are not used in a swiftpm target. I would need to look at the latest version to see if xcframeworks are not needed to build swift pm targets 😉