Support package managers other than Cocoapods. about google-api-objectivec-client HOT 8 CLOSED

s/Supper/Support/?

As noted on in the Readme, this library has been replace by a new version (REST base). In any case, we're open to support other systems, PRs to help get things going are always welcome as odds are someone wanting that system will know a little more about it then us.

from google-api-objectivec-client.

1. Yes
2. Ment to open this issue against the new REST based project.
3. Using cocoa pods as a "library" generator as that project I think would makes opening a small PR that supports alternate systems tricky. Dynamic frameworks (which is how modern iOS development works now) or Carthage or SwiftPM, hard it requires a rather large refactor to the build system.
4. It also adds some burden to the maintainer as it adds a dependency to the release and feature updates of each of those systems, sometimes keeping up with cocoa pods is enough of a challenge.
5. I can look at a PR, but it would be very focused on my needs as consumer and not Google's needs a Provider. It might also require coordination across many of the other sub specs, documentation, etc.
6. In the past I have not had good success submitting PR's to google projects.

from google-api-objectivec-client.

Np, anything you can do to help us figure out what is needed would be helpful. The hardest part from my POV has been trying to get #import statements right as how headers for dependencies are found seems to very based on the packaging system. 😦

Shipping as a framework is one of the interesting problems spaces (to me atleast). At WWDC last year Apple called out (in I believe the performance session) having too many frameworks is actually a problem as each framework impacts startup time for the App. So while frameworks make some things easier, it doesn't seem to scale to an App using a lot of dependencies.

Another pain point with frameworks is code signing. We've been through a few PRs on things where folks say we should be setting up everything so the framework signs, but Xcode 8.3 wants to remove all those settings in the project saying the signing should be happening when the shipping app is finally signed.

from google-api-objectivec-client.

Thanks for having the discussion I think its important to make using Frameworks as easy as possible for clients and its what I try to do at work. With the development of Swift and SwiftPM and modern obj-c frameworks I'm not sure the current cocoa pods setup is ideal.

to your point about #import statements Modules go a long way for this. If you have a module no matter the packaging system it is always import module.header. ex: @import GoogleAPIClient.GTLDrive #import <GoogleAPIClient/GTLDrive.h> Swift even has symbol based imports (nice if you follow include what you use) import GoogleAPIClient.GTLObject. This works for SwiftPM, Carthage, Cocoapods, Git-submodules etc. Search paths may need to be changed but Xcode will do this when you link a dependency. An additional benefit is the ability to distribute dependencies say via Buck, Bazil; or Framework binaries via Carthage, Git-LFS, or cocoapods with a Binary framework pod spec etc.

to your point about too many frameworks, I think that is a client/tooling problem and not necessarily best solved at the SDK/framework level (pre-optimization). The Clients decide how many frameworks they want to link. They can choose to optimize app startup by combining frameworks with libtool Which is further helped with modules. Tooling should also strip unused symbols so which reduces the concern that one large Framework with many features would have a bad effect on file size. I think at that same WWDC apple was saying when they talk about apps with too many frameworks they mean apps with dozens + of frameworks at thats what the engineers were saying at the Labs. There was also a not well publicized bug in dyld (that was fixed) which exacerbated the issue for each Framework that was linked If you search for dyld app launch time You should get some valuable Info. One famous case: images loaded: 290 (235 from dyld shared cache)

I can't speak to signing in general but the the Xcode 8.3 approach is pretty much the approach my peers have been following for as long as we have written frameworks.

Google Chrome Cast SDK is provided as a framework and it is very easy to integrate into any build system. If you skip a required setup step it provides a handy assert and error message about what you forgot.

from google-api-objectivec-client.

Also for Swift client code a Module is required regardless. It would be nice if this system provided it instead of having to generate one via the bridged header mechanism. Bridged headers allow for good obj-c interop but they pollute Swift's namespace with every Symbol from the generated Module.

from google-api-objectivec-client.

I took a look at some of this because right now I have a prototype app that uses Auth/Session/Drive libraries. And a mix of Carthage + Cocoapods. The last bit is not ideal. I tried isolating the cocoa pods segment of the build in a library which stinks because bridging-headers (required to link Swift) to these libraries are not allowed in framework targets. I think creating a Nice wrapper around this

I also don't know when these projects were generated but new incantations of pod lib create generates projects more compatible with Carthage. ( I tried this but got caught up in the rabbit hole of figuring out header paths etc). I wasn't able to figure out how to get cocoapods to hoist a Library's Dependency's Header into the module it defines. I think that would require nested/umbrella frameworks/libs which apple doesn't allow on non Mac platforms.

I think a path forward would be some make script that generates an xcproject from something like a list of service libraries that builds a .framework.

• Drag the framework into your project type dependencies
• Carthage managed dependencies from source or from binary.
• It could maybe also spit out a Package.swift and work with SwiftPM.

I also saw numerous build issues due to @parameter doc strings not matching the actual definitions in the GTMAuth library that this library references in Sample Projects..

from google-api-objectivec-client.

Pod::Spec.new do |s|
  s.name             = 'DriveKit'
  s.version          = '0.1.0'
  s.summary          = 'A meaningful summary'

  s.description      = <<-DESC
    TODO: Add long description of the pod here.
                       DESC

  s.homepage         = 'https://github.com/Aaron Crespo/DriveKit'
  s.license          = { :type => 'MIT', :file => 'LICENSE' }
  s.author           = { 'Aaron Crespo' => '[email protected]' }
  s.source           = { :git => 'https://github.com/aaroncrespo/DriveKit.git', :tag => s.version.to_s }
  s.social_media_url = 'https://twitter.com/aaroncrespo'

  s.ios.deployment_target = '8.3'

  s.source_files = 'DriveKit/Classes/**/*'

  s.framework = 'UIKit', 'Foundation'
  s.dependency 'GoogleAPIClient/Drive', '~> 1.0'
  s.dependency 'GTMAppAuth'
  s.dependency 'GTMSessionFetcher'

end

This above pod spec allows an example project to import GTMAppAuth which I haven't been able to do. going to try and use the generated project to feed into Carthage. Carthage builds all Public schemes which is easy enough to setup.

from google-api-objectivec-client.

its a round about method but it means my app can use all/only Carthage dependencies, with a simple implementation-less wrapper repo around cocoapods for fetching google services.

test ❯ carthage update
*** Fetching DriveKit
*** Checking out DriveKit at "bcd0735d433905c3262a0fd4a032fecbfb10616c"
*** xcodebuild output can be found in /var/folders/cw/fgcj0f714137j3_89vss95c80000gn/T/carthage-xcodebuild.2GqWxL.log
*** Building scheme "GTMSessionFetcher" in DriveKit.xcworkspace
*** Building scheme "GoogleAPIClient" in DriveKit.xcworkspace
*** Building scheme "AppAuth" in DriveKit.xcworkspace
*** Building scheme "GTMAppAuth" in DriveKit.xcworkspace
test ❯ 

After the above the client can no link and copy frameworks in a straight forward manner from carthage docs.

from google-api-objectivec-client.