Error about transitive dependencies that include static binaries

[chrisellsworth]

I'm getting the following when I install the FirebaseUI pod (0.3.0):

± |master ✗| → pod install
Updating local specs repositories
Analyzing dependencies
Downloading dependencies
Installing Bolts (1.5.0)
Installing FBSDKCoreKit (4.8.0)
Installing FBSDKLoginKit (4.8.0)
Using Firebase (2.4.3)
Installing FirebaseUI (0.3.0)
Installing Google (1.2.1)
Installing GoogleAppUtilities (1.0.0)
Installing GoogleAuthUtilities (1.0.1)
Installing GoogleInterchangeUtilities (1.1.0)
Installing GoogleNetworkingUtilities (1.0.0)
Installing GoogleSignIn (2.4.0)
Installing GoogleSymbolUtilities (1.0.3)
Installing GoogleUtilities (1.1.0)
[!] The 'Pods-my-project' target has transitive dependencies that include static binaries: (/.../my-project/Pods/Google/Libraries/libGGLCore.a and /.../my-project/Pods/Google/Libraries/libGGLSignIn.a)

Running CocoaPods 0.39.0. I'd love to be able to pull in a version of FirebaseUI that doesn't have all of the additional dependencies for various login providers.

[ianzitow]

Me too!

[stefanp312]

Same with me. I fixed it by doing this with my pod file.

pod 'Firebase'
pod 'FirebaseUI', '= 0.2.6'

[henriquesobral]

+1

[asciimike]

Let's separate this into two issues:

1. Transitive deps include static binaries: this is an issue with the way Google does it's libraries (and by extension, how we do our libraries). I believe if you don't use_frameworks! it will work, since all the deps will be static, though this prevents the use of dynamic frameworks.
2. Splitting out auth providers into subspecs (or at the very least, a split between the core features and the auth features). Originally we wanted to provide everything together and see how people were using it to get a sense of how it should go. I see two options for this: FirebaseUI/Core and FirebaseUI/Auth or FirebaseUI/Core and FirebaseUI/Providers. Anyone have any preference?

@davideast thoughts?

[asciimike]

Item 2 will be fixed in #24, as it will allow for /Auth and /Core. /Provider is in the works, but will take a little while.

We're taking a look at the cases where Google fails out due to transitive deps on static libs--I think it's what I mentioned above, so I would try to use them statically if possible.

[chrisellsworth]

Thanks Mike!

Indeed removing use_frameworks! does the trick. I'll stick with that until another pod necessitates otherwise.

As far as /Auth vs /Provider goes, I'd be a fan of separate /Providers for each provider since the Google support libraries appear to be fairly hefty and it leaves some room for expansion without further bloat should other providers be supported in the future. But I don't plan to use auth at all initially, so I defer to someone whom it may matter more to :)

[asciimike]

Yeah, we're thinking the same thing--though we'll start with /Auth and then move to /Providers in a later release (keeping /Auth as the sum of all providers).

Any reason you're not planning on using auth? Just don't need it while prototyping the app, too difficult to set up providers or security rules, something else?

[chrisellsworth]

Something else :) I'll explain over email as not to derail this thread

[asciimike]

Ok, I'm going to mark this as "Works as Intended" after 0.3.1 (just shipped) since the fix here is to remove use_frameworks! or switch to using FirebaseUI/Core if you don't need auth.

If you need to use use_frameworks for Swift only libraries in addition to FirebaseUI/Auth in the future, please create a new bug that references the issue, and we'll see about how to fix it. #26 has been created to track multiple providers (which will partially solve the issue for users of auth providers other than Google).