No such module 'PPRiskMagnes', continued

[eseay]

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:

• No such module 'PPRiskMagnes' #711
• Archive failure No such module 'PPRiskMagnes' #679
• Issues building to test device using SwiftPM #726

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!

[scannillo]

👋 Hi @eseay - I appreciate you opening this issue and bringing this to our attention again. It is definitely a weird one.

So, we have a sample app that pulls in Braintree via SPM running on our CI (we have builds for both XCode 12.5 and XCode 13 beta). In the past few weeks/months we haven't seen this issue surface at all again.

However, we will do our best to dig on this some more when we have the time. Will keep you posted when that happens!

[eseay]

@scannillo Thanks for keeping it on your radar! Hopefully this becomes no longer an issue when we move to Xcode 13 in our CI pipelines, but unfortunately it's seeming to have started happening even more frequently since I first posted this issue.

I'm not requesting any additional action from your team at this point beyond what you've already said above ☝️, but I did want to follow up to indicate that my plan for a short term workaround is to roll back to v5.2.0, which is the last version I've been able to use without issue. If you have any explicit concerns about this approach (security, critical functionality, etc.), please just let me know. Thanks for you and your team's continued efforts and assistance!

EDIT: Before rolling back, I decided to randomly try something that seemed completely unrelated to Braintree in particular, which appears to have resolved the issue.

In our GitHub Actions workflows, we have a caching step that was taken directly from the actions/cache repository. The intent of this step is to theoretically speed up our workflows by removing the need to download all the packages from their remote locations and to rely on a download within GitHub Actions when possible.

- name: Load Swift Package dependencies from cache
  uses: actions/[email protected]
  with:
    path: .build
    key: ${{ runner.os }}-spm-${{ hashFiles('**/Package.resolved') }}
    restore-keys: |
      ${{ runner.os }}-spm-

The change is that I have removed this step from all of my workflows. The results:

• Braintree is compiling as expected
• Everything else is still compiling as expected
• No meaningful decrease in workflow performance

Though it seems the solution required no changes to the BT integration, I thought it may be helpful to post this here for others, as I have only seen this cause issues with the BT framework, and since the caching step is officially promoted by GitHub, it seems like something that others might be doing.

[scannillo]

Hey @eseay - thanks so much for posting this and providing context for others to follow, that is super helpful. I am glad it is resolving your issue! I'm going to keep this issue open a few more days 1) to make sure it consistently resolves your issue and 2) so others can find it.

Please do post if things change.

[eseay]

@scannillo Unfortunately while it does seem to have greatly reduced the frequency of the issue, it seemingly has not eliminated it. We'll be moving all of our development to Xcode 13 in the next release cycle, so hopefully we may see improvement then.

[simonpierreroy]

I have been tracking the issue for a year, it is not fixed. It has been broken since Xcode 12.0 b4! I do not think it will be anytime soon (I still hope :) ). See Xcode 13 release notes

Could you go fully source code?

Known Issues
Using Swift packages with binary targets may result in a “no such module” error when attempting to import the module of a binary target. (77465707)

[eseay]

While I expect that distributing the source code of that framework may pose a some security implications, based on @simonpierreroy's note I do wonder if there is another way that we could go about integrating the framework. I obviously prefer to use Swift PM for all my dependencies, but I am willing to use an alternate approach - like download and manual drag+drop integration - if it means my builds will not fail on CI as frequently as they do.

I've gotten to a (sad) point where now if I see a PR validation job has failed after 5 minutes, I just instinctively know it was because of PPRiskMagnes and just admin merge the thing to avoid having to wait for indefinite number of additional attempts until the job passes.

[scannillo]

Hi @eseay - check out the changes in this latest release v5.4.4. It includes a few optimizations for how each payment module includes PayPalDataCollector (aka PPRiskMagnes). Let me know if this helps with your issue at all.

[ikorich]

v5.5.4: error: Missing package product 'PPRiskMagnes' (in target 'xxx' from project 'xxx')
update lib - not work
remove/add again - not work
clean derived data - not work

[scannillo]

Hi @ikorich - if you think there's a bug or issue with that version, please open a separate GitHub issue.

[ikorich]

hi @scannillo , you can close ticket, updated dependencies and now it works

[scannillo]

@ikorich - your issue was different than @eseay's original issue filed here. @eseay any updates from using the latest braintree_ios version?

[scannillo]

@simonpierreroy - any updates on your end using v5.4.4?

[simonpierreroy]

@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 ;)

[eseay]

@scannillo Sorry - haven't looked at this in a minute. I ended up going with a workaround in the interim of just downloading the xcframeworks from this repo and manually integrating them. I will try again moving back to SPM. Stay tuned for updates!

[SentoCrespo]

+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.

[hbanzon]

I'm also encountering this issue, happens only when running a CI build within my unit testing module on CircleCI, but I don't encounter it when I'm running the application locally via Xcode.

[simonpierreroy]

This is normal, due to the bug mentioned here #735 (comment) , 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)

[scalessec]

I'm seeing this as well with every build, including with the latest 5.5.0 release. Is there any known version of Braintree that works reliably with Swift Package Manager?

[scannillo]

👋 Hi everyone. This is more of an exploratory comment/question - The braintree_ios SDK 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 use BraintreeDataCollector
😄 if you use none of the above, but use PayPalDataCollector

[GabrielMassana]

v5.5.0
So annoying that CI is always failing.
Do we have a solution for this?

[simonpierreroy]

Again, there is nothing you can do about it! Apple claims a fix in Xcode 13.2b2 (the bug as been there since (Xcode 12.0). I will have to investigate soon.

[eseay]

As @simonpierreroy said, this is from the Xcode 13.2 Release Notes.

Resolved an issue where Swift packages with binary targets sometimes failed with a “no such module” error when attempting to import the module of a binary target. (77465707)

I will be testing at the beginning of my next release cycle now that 13.2 appears to be available on GitHub Actions.

[scannillo]

Hi @eseay - thanks for updating this thread with that information. Please let us know if Xcode 13.2 resolves your issues!

[simonpierreroy]

@scannillo you will need to fix the package.swift . The dependency on the xcframework (the binary targets) needs to be explicit (in the dependency section where they are imported) ! That was removed to try fix the issue, but just made it worst.

[agarcia-wish]

Hi, I am experiencing the same error:
Xcode Version 13.2 (13C90)

Error:

▸ Compiling PPDataCollector.swift
❌  /Users/gitlab-runner/Library/Developer/Xcode/DerivedData/Wish-ezfzgxekortwqyfbwqqlhjivqcye/SourcePackages/checkouts/braintree_ios/Sources/PayPalDataCollector/Public/PayPalDataCollector/PPDataCollector.swift:1:8: no such module 'PPRiskMagnes'
import PPRiskMagnes

Bitcode is disabled in my project. It compiles correctly locally but when I run it on CI it fails. CI is using gitlab and they are self-hosted runners using the exact same version and configuration as I have in my local machine.

[simonpierreroy]

That is normal! The package file has not been fixed for 13.2! #735 (comment)
c.c. @agarcia-wish @scannillo. Need to add back the binary dependencies entry for each module that use a binary !

[mthole]

I also hit this issue on Xcode 13.2 with Braintree 5.5.0, on CI.

[scannillo]

@simonpierreroy That is normal! The package file has not been fixed for 13.2! #735 (comment)
c.c. @agarcia-wish @scannillo. Need to add back the binary dependencies entry for each module that use a binary!

Hi Simon. I don't think reverting that change is going to provide a fix here, as the way we have it structured now (including the binary dependency in the library target) is the intended use of binary dependencies via SPM according to Apple's docs.

This seems to me that Apple still hasn't properly fixed this bug.

[mbuchetics]

Are there any workarounds? I am using Braintree Drop In and have the same issue on our CI Mac Mini, which builds using fastlane.

[simonpierreroy]

@scannillo this is true, but you still need to
Make the dependency explicit in the file where you use it, as any normal dependency.

[agarcia-wish]

Any update on this? @scannillo

[srikanth-vm]

Any workarounds for this issue ?

[JavierSilvaFreeNow]

Hey all, I'm afraid I have to bump the issue since I've run into it as well.

Some details:
v5.6.2
Using Xcode 13.2 (13C90), targeting iOS 15.2
We're trying to migrate the library from Cocoapods to SPM, and we use both BraintreePaymentFlow and BraintreeThreeDSecure modules.

This is becoming a blocker for our efforts to have a single dependency manager in our project, so we hope it can be resolved soon. Thank you.

[simonpierreroy]

@scannillo did you apply the fix that should fix it ? The fix: add an explicit dependency of the binary targets for modules where there is an import statement of that binary.

[DrBeak1]

Also bumped into this recently.

braintree_ios: v5.6.2
Xcode: 13.2.1 (13C100)

We got some suggestion that including PayPalDataCollector would resolve the issue, but that didn't work. We also tried adding the PayPalDataCollector manually to our project, which also didn't work.

For now, we just resorted to using the Braintree cocoapod to unblock our CICD.

[simonpierreroy]

Here is the fix based on Xcode 13.2, it fixes a dependency graph issue introduced in Xcode 12.0 for binary targets in swiftPM. But even if the fix is there now in Xcode 13.2, you need to properly declare the dependency graph! @scannillo could we have a branch with the fix below in the image for us to try :) Please apply this idea for all the import of other binary targets. #735 (comment)

[jaxdesmarais]

Hello @simonpierreroy (and everyone else following this thread) - we've put up a test branch for this named update-package-dependencies in 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.

[simonpierreroy]

Thank you @jaxdesmarais. Good idea, let us see if this helps folks in the 🧵. I should work except if Apple has not really fixed the issue. I am happy to update my personal feedback (FB9125479 open since Xcode 12.0) with any findings from this 🧵.

[eseay]

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?

@jaxdesmarais I have pulled in your branch, and I have since had 3 consecutive CI builds run successfully - no failures yet. Prior to these changes, it would fail on the first try.

I think this looks promising!

@simonpierreroy can you report back when you confirm this works for your project too?

[simonpierreroy]

@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.

[DrBeak1]

@jaxdesmarais the changes in update-package-dependencies branch passed for us.

[jaxdesmarais]

Thanks for testing @DrBeak1 and @eseay! We'll update you all here once we've cut a release with this change included.

[srikanth-vm]

We will check once on our end too. @jaxdesmarais Sorry to rush you, but do you have an ETA in mind ?

[jaxdesmarais]

@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.

[GabrielMassana]

We used update-package-dependencies branch and our CI was able to build without the 'PPRiskMagnes' error.

[jaxdesmarais]

Thank you all for testing! This has been released in version 5.6.3.

[hbanzon]

This is amazing updating now

[eseay]

Wonderful! @jaxdesmarais @scannillo thank you for working through this with us all!

[jaxdesmarais]

👋 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. 🚀

[mrazam110]

Hi,

I just produce the similar issue with Braintree 5.19.0 and BraintreeDropIn 9.8.0 with SPM
I am using BraintreeApplePay, BraintreePayPal and BraintreeDataCollector.

Anyone else having similar issue?

[jaxdesmarais]

Hello @mrazam110 -

The errors you are seeing appear to be unrelated to the initial issue reported here. As a first step have you cleared derived data and cleaned (cmd + k) the Xcode project? If you are still running into errors, can you additionally share both the Xcode and Swift versions your project uses so I can attempt to reproduce?