cocoapods / cocoapods Goto Github PK

Are the header files for each project grouped into folders or are they placed in one directory with each other?

For instance,

Would I import a dependency doing:

#import "Project/Project.h"

or

#import "Project.h"

When the user has an app that uses ARC, the pods that don’t require_arc should be compiled with -fno-objc-arc. See for instance: pokeb/asi-http-request#210

The user’s Podfile should indicate that the app uses ARC:

platform :ios
requires_arc!
dependency 'ASIHTTPRequest'

With the addition of the `platform' attribute being important in a Podfile, it became clear that we’ll have to rethink the way in which a Podfile is defined a bit. For now (in master) I have changed it to be the same as a normal specification:

Pod::File.new do |f|
  f.platform :ios

  f.dependency 'JSONKit'
end

However, this will become more of an aesthetic issue once we, for example, add the API to define dependency groups:

Pod::File.new do |f|
  f.platform :ios

  f.dependency 'JSONKit'

  f.group :debug do
    f.dependency "Kiwi", "1.0"
    f.dependency "LRMocky", "0.9.0"
  end
end

We could create a separate DSL for a Podfile which assigns attributes without the = sign, which would make it possible to retain the previous way of defining a Podfile:

platform :ios

dependency 'JSONKit'

group :debug do
  dependency "Kiwi", "1.0"
  dependency "LRMocky", "0.9.0"
end

I’m still on the fence about this, please let me know what you think.

This is for projects that use a scripting language such as MacRuby, Nu, or JSCocoa.

We can specify which system frameworks are required by adding them to OTHER_LDFLAGS but as this is a common case I'd like to see this as a natural part of the podspec file.

Something like:

Pod::Spec.new do
  ...
  frameworks 'SystemConfiguration', 'CoreLocation'
end

How does one handle projects with nested directories of source files? I tried creating a podspec for RestKit that included:

source_files 'Code/*'

This resulted in the whole directory structure being included in the Pods group in Xcode.

I can #import RestKit.h (from Pods/RestKit.h), but it subsequently imports headers from nested directories:

#import "Network/Network.h"
#import "Support/Support.h"
#import "ObjectMapping/ObjectMapping.h"

Xcode reports no such file or directory for all three of these. Is this a header search path problem?

On a side note, libraries like this will surely introduce naming conflicts (as mentioned in issue #9).

• add platform where necessary
• use framework/frameworks attribute accessors instead of specifying it in OTHER_LDFLAGS
• use library/libraries attribute accessors instead of specifying it in OTHER_LDFLAGS
• remove -Objc -all_load from OTHER_LDFLAGS

Add more if I forgot something.

• Guides made from the wiki pages
• Using the Rails guides templates

Some projects include the source of dependencies within their repository (for example the facebook-ios-sdk project includes the SBJson source files directly).

How should situations like this be handled? My thoughts were either 1) Petition the project to remove the dependency source, 2) fork the project and remove the dependencies. The former may be difficult at first, but as cocoapods grows, many projects may opt to provide a Podfile from the start (or at least I hope!). The latter would require the additional work of keeping the fork up to date.

• Use general design from rubygems.org. (Thijs was going to do some adjustments to it.)
• Simple Rack/Sinatra app.
• Use Picky to search pods, filter by platform, ARC, etc.
• App should have a post-push action which github can call once somebody pushes to the specs repo. Once the call is received, the app should update a local checkout of the specs repo, load all specs (IN SAFE MODE, WE DON’T WANT RUBY FS CODE TO WORK!!) and re-create the index for Picky.

If a library includes Objective-C categories and requires them to function correctly, we should be able to specify this in the podspec and have the ObjC and all_load linker flags added automatically.

E.g.:

We can specify which system frameworks are required by adding them to OTHER_LDFLAGS but as this is a common case I'd like to see this as a natural part of the podspec file.

Something like:

Pod::Spec.new do
  ...
  requires_objc_categories true
end

I want to run the CocoaPods spec suite on Travis, to do so we need to help them with getting a working OSX VirtualBox image setup for Vagrant.

The details on how to create a bootable image are a bit hard to find out, but at the very least we have found a working one on bittorrent which should be good enough to get started with. Although it’s preferred if we have the instruction to setup the image completely from scratch.

Currently the user still has to perform these steps:

• Link against libraries that the pods library links against
• Add header search paths that were added to the pods library

The user also has to perform these steps, but this might just be the simplest way that xcode allows:

• Add pods static library to workspace
• Configure project to Always Search User Paths and set User Header Search Paths to $(BUILT_PRODUCTS_DIR)

In addition, some changes to the pods static library project had to be made:

• Change Public Headers Folder Path to $(TARGET_NAME)
• Change Installation Directory to $(BUILT_PRODUCTS_DIR)

Most of this info was taken from: http://blog.carbonfive.com/2011/04/04/using-open-source-static-libraries-in-xcode-4

The RKTwitter example (and others) don't build out of the box anymore: Xcode doesn't find the implicit dependency in the workspace.

Bisected to 55e11e5

The podspecs bundled as fixtures in spec/fixtures/spec-repos/master.tar.gz need to be manually updated after pulling from alloy/cocoapods-specs. It makes more sense to me to include cocoapods-specs as a submodule so it's easier to test podspecs as they are in production. However, I got stuck on two issues when I tried to do this myself:

• The functional tests become a moving target as the search results will change with specs being added.
• Including an old podspec (e.g. ASIHTTPRequest 1.8) alongside a newer one (1.8.1 is the only one currently there) for testing purposes becomes nontrivial.

The other problem here is someone will still have to remember to keep the cocoapods-specs submodule moving along. So I'm thinking there's a better solution out there.

tl;dr it would be nice to test with production podspecs but in a more controlled environment.

The relevant repos are:

• cocoapods
• cocoapods-specs
• xcodeproj
• cocoapods.org

This would allow you to do arbitrary stuff to the generated project, such as enabling GC support (for MacRuby, for instance).

I think something like:

post_install do |project|
  # project is an instance of Pod::Xcode::Project
end

Or maybe we should pass in the Installer instance, mainly because this gives access to the Installer::Target instances as well, which have some metadata about filenames.

(Not sure if this ticket should be filed against cocoapods or cocoapods-specs, anyways I will try here.)

I had a glance at the pod specs currently written, and one thing that surprised me is that there is no mention of software licenses for code. I believe this can be an issue as people might quickly bundle code and unwillingly violate the license terms. Some licenses require attribution for instance.

As the project is still young it's probably a good idea to introduce a license field to the pod spec now, before we have a sizable number of specs.

I am willing to provide a patch if you agree with the idea.

With most of the pressing issues done and fleshed out, it’s time to start supporting more loose ways to get libraries in an app project. We should make it so that it's very easy for users to contribute specs to the community, because although it’s nice for the user that they can fetch any library, it doesn’t help the community if these stay hidden in application repos.

So I propose the following:

• If the repo contains a podspec (and it is assumed to be up-to-date for the repo's state), then the user only has to specify the remote. CocoaPods will then fetch this repo first and use the podspec from the checkout to resolve dependencies.

  dependency "Kiwi", :git => "https://github.com/allending/Kiwi.git", :commit => "93088050d8d68797578ab99c41c07492e4ebd51c"

• If the repo does not contain a podspec, or it's not working with the current state of the repo, then the user can specify the proper attributes by, in essence, building a podspec. This means we don’t have to invent yet another API and it’s easy to move out working podspecs to the specs repo.

  dependency do |s|
    # `s` is an instance of Pod::Specification
    s.name = "JSONKit"
    s.version  = '1.5'
    s.source = { :git => "https://github.com/johnezang/JSONKit.git", :commit => "c2ef69242b60dc2475328b08131f9aa3078a51fb" }
    s.source_files = "JSONKit.*"
  end

If it makes sense, that is.

Probably the simplest way to make this work is to:

• Collect all resources, that need to be included in the app bundle, in Pods/Resources. (These may be copies or symlinks, whatever works best.)
• Create a script that copies all files/directories it finds in Pods/Resources into $UNLOCALIZED_RESOURCES_FOLDER_PATH.
• Make the user add a ‘Run Script’ build phase which calls that script.

Some related info: http://stackoverflow.com/questions/868184/add-resources-to-an-xcode-project-recursively-with-applescript

As I was dealing with RestKit I found that it is really setup to build many small libraries depending on how its used. We should reflect this somehow inside of the podspec as a grouping of source files and dependencies for each target. On the Podfile side you can then list which configurations you want to load from a given dependency.

This would allow a little better control over what source gets brought in.

Add a command that will configure the specified Xcode project according to the setup wiki page and create a Xcode workspace containing the user’s project and the Pods project.

So, getting started with CocoaPods should not be more than:

$ pod setup App.xcodeproj
$ echo 'dependency "CocoaLumberjack"' > Podfile
$ pod install

Here's what I did:

1. Create new Xcode project (e.g. iOS > Empty Application) and add a little Podfile (platform :ios, dependency 'ASIHTTPRequest').
2. $ git clone git://github.com/alloy/cocoapods.git && cd cocoapods && rake standalone

Here's what I got:

$ cd ../App && ../cocoapods/pod install --verbose
Installing dependencies of: /Users/nolanw/Desktop/App/Podfile
==> Installing: `ASIHTTPRequest' version `1.8.1'
  * Downloading: `ASIHTTPRequest' version `1.8.1'
git init
Initialized empty Git repository in /Users/nolanw/Desktop/App/Pods/ASIHTTPRequest/.git/
git remote add origin 'https://github.com/pokeb/asi-http-request.git'
git fetch origin tags/v1.8.1
remote: Counting objects: 5295, done.
remote: Compressing objects: 100% (1376/1376), done.
remote: Total 5295 (delta 4064), reused 4991 (delta 3817)
Receiving objects: 100% (5295/5295), 2.80 MiB | 539 KiB/s, done.
Resolving deltas: 100% (4064/4064), done.
From https://github.com/pokeb/asi-http-request
 * tag               v1.8.1     -> FETCH_HEAD
git reset --hard FETCH_HEAD
HEAD is now at 404bbfe Comment tweak to make the behaviour a tiny bit clearer
git checkout -b activated-pod-commit
Switched to a new branch 'activated-pod-commit'
==> Installing: `Reachability' version `2.0.4'
  * Skipping download of `ASIHTTPRequest' version `1.8.1', pod already downloaded
==> Generating Xcode project and xcconfig
Oh no, an error occurred. Please run with `--verbose' and report on https://github.com/alloy/cocoapods/issues.

undefined method `[]' for nil:NilClass

I tracked it down to installer.rb line 42, group = xcodeproj.add_pod_group(spec.name), but that's as far as I got.

The Podspec class can then have (additional) attributes that configure the project. For instance, for what platform the project is and whether or not you want BridgeSupport metadata created from all headers.

There are a few libraries which do not have discreet releases or versions. How shouldthe specs be handled for these kinds of projects?

It would be really handy if there was a wiki page detailing how to get up and running with a local clone of the cocoapods project for development, assuming a MacRuby installation alongside a regular Ruby installation (or rvm or whatever).

• What version of MacRuby?
• What gems are needed?
• Best way to run the specs etc

I was reminded of ARC incompatibilities after starting a new iOS5 project recently. I haven't been keeping up with ARC, but I'm curious as to how what impact ARC has when it comes to integrating external dependencies. Would it make sense to add a flag for this (perhaps like in the example below), or describe this architectural constraint somewhere else?

Pod::Spec.new do
  ...
  arc true
end

If everything is recompiled into a static library, is this less of an issue? How are library creators and maintainers dealing with this now in their repositories?

As we're all trying to help build the podspec repo, it would be great if there was a way to make sure a podspec is formatted correctly and can compile. Currently this is manual process (if tested at all). It would be great if there was a handy tool for this :)

Specifications should indicate which platforms are supported and an osx static library Xcode project template has to be added.

The Xcode installation at home (4.2 4D151a), works except during archiving. For normal builds it creates a structure like:

DerivedData
\ - PRODUCT_NAME
  \ - Build
    \ - Products
      \ - Debug-iphoneos
        \ - libPods.a
        | - PRODUCT_NAME.app
        | - Pods
          \ - *.h

However, while archiving it creates:

DerivedData
\ - PRODUCT_NAME
  \ - ArchiveIntermediates
    \ - PRODUCT_NAME
      \ - BuildProductsPath
      |  \ - Release-iphoneos
      |    \ - libPods.a (symlink)
      |     | - PRODUCT_NAME.app (symlink)
      | - IntermediateBuildFilesPath
        \ - UninstalledProducts
          \ - libPods.a
          | - Pods
            \ - *.h

As you can see, it creates a symlink to the lib in Release-iphoneos, but not to the Pods headers dir. This worked at the office with an older Xcode, but I might have forgotten about some configuration steps I made manually. Regardless, it should of course be possible to create an archive with a project that uses a static library, so this needs investigation.

(As a workaround, didn't have time to debug this now, I temporarily added the headers to the app project.)

I'm currently having the following issues getting the Kiwi podspec to work properly:

• Kiwi does not compile with GCC. It needs to use LLVM. How do we approach this? Personally I'd like to see cocoa pods just use LLVM and be done with it.
• Kiwi requires SenTestingKit and even though I've added -framework SenTestingKit to the OTHER_LDFLAGS in the podspec this doesn't seem to affect the building of libPods.a so the build is failing with "SenTestingKit/SenTestingKit.h not found".

Any suggestions on how to tackle these issues?

• http://twitter.com/myell0w/status/134955697740840961
• http://news.ycombinator.com/item?id=3009154

There are probably more.

Hello,

I followed every step as outlined in the readme (including the same Podfile) for testing. But in pod install App.xcodeproj I get an error. Here is the --verbose output of my second run, as proposed in the error message:

pod install App.xcodeproj --verbose
Installing dependencies of: /Users/net/Desktop/ThrowAways/co/Podfile
==> Installing: JSONKit' version1.4'

• Skipping download of JSONKit' version1.4', pod already downloaded
  ==> Installing: Reachability' version2.0.4'
• Skipping download of ASIHTTPRequest' version1.8.1', pod already downloaded
  ==> Generating Xcode project and xcconfig
• Copying contents of template directory /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/Gems/1.9.2/gems/cocoapods-0.2.0/xcode-project-templates/cocoa-touch-static-library' to/Users/net/Desktop/ThrowAways/co/Pods'
• Writing Xcode project file to /Users/net/Desktop/ThrowAways/co/Pods/Pods.xcodeproj' Oh no, an error occurred. Please run with--verbose' and report on https://github.com/alloy/cocoapods/issues.

undefined method []' for nil:NilClass /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/Gems/1.9.2/gems/cocoapods-0.2.0/lib/cocoapods/xcode/project.rb:279:inobjects'
/Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/Gems/1.9.2/gems/cocoapods-0.2.0/lib/cocoapods/xcode/project.rb:302:in files' /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/Gems/1.9.2/gems/cocoapods-0.2.0/lib/cocoapods/installer.rb:114:inconfigure_project:'
/Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/Gems/1.9.2/gems/cocoapods-0.2.0/lib/cocoapods/command/install.rb:46:in run' /Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/Gems/1.9.2/gems/cocoapods-0.2.0/lib/cocoapods/command.rb:51:inrun:'
/Library/Frameworks/MacRuby.framework/Versions/0.10/usr/lib/ruby/Gems/1.9.2/gems/cocoapods-0.2.0/bin/pod:9:in <main>' /usr/bin/pod:19:in

Any ideas?

Regards,
sunatmidnight

I was wondering what the long-term plan was in terms of where pod specs will be hosted.

The current model, similar to HomeBrew, requires developers to open a pull-request for their spec and then once they have push access, maintain a local clone of the podspec source and keep their specs up-to-date.

I was wondering if this was intended to always be the way that it works or if there was any plan to move towards a more centralised RubyGems style spec server. In this case, instead of having Gemspecs that are used to create gems which are published, we are publishing the specs themselves.

Or is there an intermediate package (like a gem) that could be created from a podspec which is then published; the CocoaPods equivalent of a gem file - a pod file, I guess?

I don't have any real answers at this point but I thought it was something worth discussing. Obviously, if we move towards a Podspec/Pod type distribution then if we use the RubyGems.org source we might get some stuff for free.

As described here: https://github.com/cocoapods/cocoapods/wiki/Sharing-pod-specifications

Bundler lets you create dependency groups, e.g. a test group that only has your test dependencies. With Rails, these are typically tied to Rails environments.

It would be nice if cocoapods supported this too. The way I would see this working is that each dependency group produces a new build product (e.g. if you have a "debug" group, you would get a libPods-debug.a library). All dependencies at a root level are included in all build products.

One use case would be: I don't want to compile my testing tools (Kiwi, LRMocky etc.) into my production app. Therefore, I'd only include these dependencies in a "test" group. I would then only link libPods-test.a to my unit testing bundle.

~/code/cocoapods/ (master *) $ pod --version
0.1.0

~/code/cocoapods/ (master *) $ ruby -v
MacRuby 0.10 (ruby 1.9.2) [universal-darwin10.0, x86_64]

~/code/cocoapods/ (master *) $ pod search http --verbose
==> ASIHTTPRequest (1.8.1)
Oh no, an error occurred. Please run with `--verbose' and report on https://github.com/alloy/cocoapods/issues.

undefined method platform' for nil:NilClass /Users/ed/.rvm/gems/macruby-0.10/gems/cocoapods-0.1.0/lib/cocoapods/config.rb:58:inios?'
/Users/ed/.cocoapods/master/ASIHTTPRequest/1.8.1/ASIHTTPRequest.podspec:21:in block' /Users/ed/.rvm/gems/macruby-0.10/gems/cocoapods-0.1.0/lib/cocoapods/specification.rb:23:ininitialize'
/Users/ed/.cocoapods/master/ASIHTTPRequest/1.8.1/ASIHTTPRequest.podspec:1:in <main>' /Users/ed/.rvm/gems/macruby-0.10/gems/cocoapods-0.1.0/lib/cocoapods/specification.rb:5:in_eval_podspec:'
/Users/ed/.rvm/gems/macruby-0.10/gems/cocoapods-0.1.0/lib/cocoapods/specification.rb:13:in from_file:' /Users/ed/.rvm/gems/macruby-0.10/gems/cocoapods-0.1.0/lib/cocoapods/specification/set.rb:58:inspecification'
/Users/ed/.rvm/gems/macruby-0.10/gems/cocoapods-0.1.0/lib/cocoapods/command/search.rb:29:in block' /Users/ed/.rvm/gems/macruby-0.10/gems/cocoapods-0.1.0/lib/cocoapods/command/search.rb:27:inrun'
/Users/ed/.rvm/gems/macruby-0.10/gems/cocoapods-0.1.0/lib/cocoapods/command.rb:51:in run:' /Users/ed/.rvm/gems/macruby-0.10/gems/cocoapods-0.1.0/bin/pod:9:in

For the purposes of obtaining the glorious treasures of bitbucket!

We probably want to add option to enable/disable automatic updating of spec repos before installing and a global way to configure such things, e.g. ~/.cocoapods/settings.yml.

Under some circumstances Xcodes syntax highlighting and code completion stops working in files where header files from pod libraries are included.

I suspect this is has something to do with cocoapods USER_HEADER_SEARCH_PATHS in the Pods.xcconfig file, making Xcode search for the headers in the BUILT_PRODUCTS_DIR.
When building the initial index, the header files are not there yet, because the Pods target hasn't been built.

A workaround which made both syntax highlight and code completion work for me was to ensure that the Pods target is built (e.g building it as a dependency for another target or adding a separate Pods scheme) and the find the workspaces folder in Xcodes Derived Data folder and delete the only Index folder there, to force Xcode to rebuild the index.

http://iosboilerplate.com

Replace all dependency management with a Podfile, or if only a Podfile is needed than it might not be necessary to fork. Whatever.

Add a generator which uses appledoc to generate documentation from all the installed Pods and install it in Xcode.

@samsoffes Any ideas/suggestions?

Generators, like this and the BridgeSupport one, should probably move out of the installer and let the installer just iterate over a list of generators which all have the same interface. E.g. #save_as(pathname).

In preparation of version 1, we need to add as many of the popular libraries as we can and see if there are some issues we still need to implement/fix.

You can always add spec of course, but this event should be just about that.