Multiple/Duplicate Protobuf Dependencies of Carthage Binary Firebase Components

[ffittschen]

Step 1: Describe your environment

• Xcode version: 11.4
• Firebase SDK version: 6.21.0
• Firebase Component: Remote Config, Messaging (and all other components depending on Protobuf)
• Component version: n/a
• Installation method: Carthage

Step 2: Describe the problem

The usage description of the Carthage documentation states that we should add a subset of the provided components to the Cartfile of a project that uses Firebase as their dependency.

The problem is: Multiple of those components internally depend on Protobuf and all of them bundle their own Protobuf.framework within the zip file used for binary distribution.

Example:

RemoteConfig
├── FirebaseABTesting.framework
├── FirebaseRemoteConfig.framework
└── Protobuf.framework

Messaging
├── FirebaseMessaging.framework
└── Protobuf.framework

When Carthage downloads these zip files it will extract its contents into the Carthage/Build/<platform> folder.

If a project depends on multiple Firebase components that depend on Protobuf, Carthage will always fail with an error like the following.

Failed to write to /Users/ffittschen/Firebase_Test/Carthage/Build/iOS/Protobuf.framework: Error Domain=NSCocoaErrorDomain Code=513 "“Protobuf.framework” couldn’t be removed because you don’t have permission to access it." UserInfo={NSUserStringVariant=(
Remove
), NSFilePath=/Users/ffittschen/Firebase_Test/Carthage/Build/iOS/Protobuf.framework, NSUnderlyingError=0x7fb827104db0 {Error Domain=NSPOSIXErrorDomain Code=66 "Directory not empty"}}

Steps to reproduce:

1. Create a Cartfile with this content:

binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAnalyticsBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseMessagingBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseRemoteConfigBinary.json"

2. Run carthage update --platform iOS

Proposed solution:

I would like to propose to either distribute Protobuf seperately instead of being bundled within multiple Firebase components, or bundle it with the Firebase Analytics component, which should always be included according to the Carthage documentation.

The Cartfile with a separate Protobuf component could look as follows. If Protobuf would be bundled within the Analytics component, the Cartfile would not look different than existing Cartfiles

Cartfile with separate Protobuf component

binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAnalyticsBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/Protobuf.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseMessagingBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseRemoteConfigBinary.json"

[ryanwilson]

Thanks for the report @ffittschen! This is a side-effect as to how we currently build and package the zip file (which turns into the Carthage release).

It's partly an issue due to how the dependencies are set up within Firebase - Protobuf is required by Messaging and RemoteConfig but not Analytics - so including it in Analytics brings unnecessary bloat for those who aren't using Messaging or RemoteConfig (for example).

That being said, I do recognize this is still a problem that we should try to fix :) we'll look at how we can work with this in our tooling and instructions, since we'd need to communicate this with users who are depending on it being included in their project at the moment.

Thanks again for the report!

[paulb777]

Whenever I've seen this occur, a retry has succeeded - presumably because the Carthage installation is parallel and non-deterministic and will only fail if multiple installations of the same framework overlap in time.

Any suggestions on how best to address this issue? It would be nice if Carthage supported dependency management.

The downside of bundling into Analytics would be a size cost for those who don't need Protobuf. The downside of bundling separately would be more complicated usability and documentation ...

There are a few other Firebase dependencies that potentially will have the same issue depending upon which subset of frameworks are selected.

[ffittschen]

Sadly retries are not working for us and they are also not working with the provided example.

Carthage does support dependencies, but only if the distribution is not as a binary (See Carthage/Carthage#1937).

I get the downsides of bundling it into Analytics, but I don't think bundling it separately would be a real downside. It would be just as complicated to use and document as with the Analytics component: 1 sentence describing that Protobuf must always be included when using component X, Y or Z. Using carthage is a choice that already comes with the acceptance of "more configuration" in contrast to CocoaPods, so I don't think that it will be too complicated for fellow developers to integrate Protobuf separately if they use Firebase components that depend on it.

[paulb777]

@ffittschen It does seem to be harder to work around than it used to be. I'll investigate a solution for the next release.