Multiple/Duplicate Protobuf Dependencies of Carthage Binary Firebase Components #5276
Comments
|
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! |
|
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. |
|
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. |
|
@ffittschen It does seem to be harder to work around than it used to be. I'll investigate a solution for the next release. |
Step 1: Describe your environment
CarthageStep 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:
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.
Steps to reproduce:
carthage update --platform iOSProposed 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
The text was updated successfully, but these errors were encountered: