undefined method `target_definitions'

[hartbit]

I'm getting this error returned from pod install on a fork of OCMockito where I added a specfile:

$ pod install Source/OCMockito.xcodeproj --verbose
Updating spec repo `master'
/usr/bin/git pull
Already up-to-date.
Installing dependencies of: /Users/david/Dropbox/Projects/OCMockito/OCMockito.podspec
Using OCHamcrest (1.7)
Generating support files
Oh no, an error occurred. Please run with `--verbose' and report on https://github.com/CocoaPods/CocoaPods/issues.

undefined method `target_definitions' for #<Pod::Specification for OCMockito (0.21)>
/Library/Ruby/Gems/1.8/gems/cocoapods-0.5.1/lib/cocoapods/installer.rb:51:in `target_installers'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.5.1/lib/cocoapods/installer.rb:83:in `install!'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.5.1/lib/cocoapods/command/install.rb:44:in `run'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.5.1/lib/cocoapods/command.rb:53:in `run'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.5.1/bin/pod:11
/usr/bin/pod:19:in `load'
/usr/bin/pod:19

And the specfile:

Pod::Spec.new do |s|
  s.name         = 'OCMockito'
  s.version      = '0.21'
  s.license      = 'MIT'
  s.summary      = 'Objective-C implementation of Mockito'
  s.homepage     = 'http://github.com/TrahDivad/OCMockito'
  s.author       = { 'Jon Reid' => 'jon@qualitycoding.org' }
  s.source       = { :git => 'http://github.com/TrahDivad/OCMockito.git', :tag => '1.0.0' }

  s.description  = 'OCMockito is an Objective-C implementation of Mockito, supporting creation, verification and stubbing of mock objects.'

  s.source_files = 'Source/OCMockito/*.{h,m}'
  s.clean_paths  = 'Documentation', 'Examples'
  s.framework    = 'Foundation'
  s.xcconfig     = { 'OTHER_LDFLAGS' => '-ObjC' }

  s.dependency 'OCHamcrest'
end

[alloy]

You need to create a Podfile which contains something like:

platform :ios

dependency 'OCMockito'

I didn’t think we still supported looked for podspec files from pod install… That needs to be removed.

[hartbit]

Oh. I had the impression that pod install could figure out the dependency from the .specfile. That would be great. Is it planned?

[alloy]

That used to be the case, but that has been deprecated, because it meant that the Pod::Specification class had to know about all the attributes a Pod::Podfile knows of (and then you would still have to specify the platform somewhere), so that will not return.

[hartbit]

Do you recommend integrating the .specfile of a library in the source repo, or should it only live in a CocoaPods repo?

[alloy]

I recommend to include it. This way people can easily install directly from your repo and you can easily keep it up-to-date for the state of the repo.

[hartbit]

Last question: if the Podfile contains the dependencies, does the .specfile need to specify them again, or will it be able to figure them out after downloading the source?

[alloy]

In the Podfile you only need to specify the libs you want to use directly, the specifications themselves will add their own dependencies. I.e. if you have this in your Podfile:

platform :ios
dependency 'OCMockito'

Then it will in fact install OCMockito and OCHamcrest.

[alloy]

I.e. in the podspec you specify the libs needed by your lib, so that the user does not have to think about this, but only depend on your lib.

[hartbit]

I think you misunderstood my question.

I now have added both a Podfile and a specfile to OCMockito. The Podfile sets it's dependency to OCHamcrest as in your example. In that case, does the specfile need that dependency too, or can I remove the redundancy?

[alloy]

Ah, I see. So, a podspec defines a library, whereas a Podfile defines an (app) project. So normally you have a podspec for the lib itself in the repo, but only optionally a Podfile that pulls in any other dependencies you have in the, for instance, the test env of your lib.

Here are examples of libPusher:

• A Podfile which pulls in the dependencies needed to work on libPusher itself.
• A podspec which is used by users to install libPusher into their project.

[alloy]

The Podfile sets it's dependency to OCHamcrest as in your example. In that case, does the specfile need that dependency too, or can I remove the redundancy?

There is no redundancy. In my example I only have a dependency on OCMockito, not OCHamcrest. But because OCMockito’s pod spec has a dependency on OCHamcrest, they will both get installed.

[hartbit]

I was speaking of the redundancy between a lib's Podfile

platform :ios
dependency 'OCHamcrest'

and that same lib's specfile:

Pod::Spec.new do |s|
  # ...
  s.dependency 'OCHamcrest' # that redundancy
end

[alloy]

Let’s start over, because I don’t know where your Podfile example came from :)

Why exactly do you have a Podfile in OCMockito’s repo?

Just to test that it works with an example app in the repo? Because the only thing CocoaPods needs in a library’s repo is a podspec.

[hartbit]

I'm confused too. Here is my reasoning and steps I took:

1. I want my library project to use OCMockito.
2. I find out that OCMockito does not use CocoaPods.
3. I create a podspec definition for OCMockito inside my project Podfile using the dependency block syntax.
4. It does not work because OCMockito header files expect OCHamcrest to be linked as a Framework. (#import <OCHamcrest/OCHamcrest.h> instead of #import "OCHamcrest.h")
5. I decide to fork OCMockito to fix the way it links OCHamcrest by using CocoaPods.
6. I create a OCMockito.specfile in my fork's repo.
7. I want to test that OCMockito compiles so I run pod install inside my OCMockito fork and get the error I first mentioned.
8. I find out from you that if I want to test OCMockito, I need to create a Podfile for it too.
9. I find out that both my specfile and Podfile for OCMockito define it's dependencies. That is why I have the impression there is a redundancy.

[alloy]

1. I want my library project to use OCMockito.

Can you give me the link to your project (if it's online)? That might make it easier for me to see what's going on and point to files/lines.

2. I find out that OCMockito does not use CocoaPods.
3. I create a podspec definition for OCMockito inside my project Podfile using the dependency block syntax.
4. It does not work because OCMockito header files expect OCHamcrest to be linked as a Framework. (#import <OCHamcrest/OCHamcrest.h> instead of #import "OCHamcrest.h")

This should work. After installing the dependencies you should have a structure like: ./Pods/Headers/OCHamcrest. One of the header search path entries in the Pods.xcconfig file is $(PODS_ROOT)/Headers, which means that if the file exists at ./Pods/Headers/OCHamcrest/OCHamcrest.h, the import statement should ‘just’ work, so there should not be a need to fork for this reason.

5. I decide to fork OCMockito to fix the way it links OCHamcrest by using CocoaPods.
6. I create a OCMockito.specfile in my fork's repo.
7. I want to test that OCMockito compiles so I run pod install inside my OCMockito fork and get the error I first mentioned.
8. I find out from you that if I want to test OCMockito, I need to create a Podfile for it too.

Yes, but if you only want to do a quick compile test, then you throw away the Podfile afterwards, you do not add it to the repo.

9. I find out that both my specfile and Podfile for OCMockito define it's dependencies. That is why I have the impression there is a redundancy.

So to conclude, under normal circumstances (and I think that that is yours) you do not add a Podfile to a repo and/or keep it around. You only use it to test that the podspec builds.

[hartbit]

This should work. After installing the dependencies you should have a structure like: ./Pods/Headers/OCHamcrest. One of the header search path entries in the Pods.xcconfig file is $(PODS_ROOT)/Headers, which means that if the file exists at ./Pods/Headers/OCHamcrest/OCHamcrest.h, the import statement should ‘just’ work, so there should not be a need to fork for this reason.

I got that working now! I was missing this OCHamcrest dependency in my project's Podfile. Facepalm.

So to conclude, under normal circumstances (and I think that that is yours) you do not add a Podfile to a repo and/or keep it around. You only use it to test that the podspec builds.

And if I want to make my library project open source later on, and distribute it with CocoaPods. Does that case warrant a Podfile in the repo?

[alloy]

And if I want to make my library project open source later on, and distribute it with CocoaPods. Does that case warrant a Podfile in the repo?

No. A Podfile is never required for distribution through CocoaPods.

A Podfile is purely to consume what CocoaPods distributes for use in your local project.

Having said that, your local project does not have to be an application, it can also be a library, like in your case. In such cases, you can have a Podfile in the repo, but it is only used to get the dependencies of you library so you can work on the library itself.

So I think what confused you, was that you have to specify OCHamcrest in the podspec for users of your library and again in the Podfile to be able to work on the library itself. In the future we’ll add something to the Podfile class which will read the podspec and include its dependencies so that you don’t have to do this anymore.

Anyways, is it all working for you now? :)

[hartbit]

You perfectly dissipated all my confusions! I'm glad to hear that Podfiles will read podspecs to include dependencies. It would help.

Thanks for taking the time to help me out!