Cocoapods: [enhancement] Please add ability to specify Podfile when doing pod-install

[dimaj]

It would be nice if one could specify which Podfile to use when setting up a project

For example, depending on what we are trying to do, we would replace pre-configured podfiles. So, for mainstream development, we would use standard Podfile and for automated testing, we would use Testing-Oriented podfile. So, we have to:

cp Podfile.AutomatedTests Podfile
pod install

it would be nice if we could just issue a command:

pod install Podfile.AutomatedTests

and it would take care of the rest for us.

Thanks.

P.S. If you think this is pointless and there's a better way to do this, I'm all ears :)

[joshkalpin]

Targets are probably what you are looking for.

pod 'RestKit'

target :debug do
    pod 'CocoaLumberjack'
end

target :test, :exclusive => true do
    pod 'Kiwi'
end

Just specify what pods you want in debug mode, for testing, etc.

[fabiopelosin]

Moreover we intend to provide support for different dependencies in a given target according to the build configuration as indicated in: https://github.com/CocoaPods/CocoaPods/issues/731.

[dimaj]

Thanks for your replies guys!

Actually, I was hoping to move away from targets. We wanted to configure the main target on demand depending on what we are trying to accomplish. Also, in my AutomatedTests podfile, I've written a post_install hook script that adds some files to the project. This is the main reason why I was looking to specify podfile as a command line argument.

Also, is it possible to duplicate a build target from within a podfile? (via built in cocoapods functionality or with a script)

Thanks again.

[alloy]

Actually, I was hoping to move away from targets. We wanted to configure the main target on demand depending on what we are trying to accomplish. Also, in my AutomatedTests podfile, I've written a post_install hook script that adds some files to the project. This is the main reason why I was looking to specify podfile as a command line argument.

Remember that a Podfile is a Ruby source file, therefore you can, for instance, check for an environment variable:

case ENV['PODFILE_TYPE']
when 'development'
  pod 'DevPod'
when 'test'
  pod 'TestPod'
else
  puts 'Specify PODFILE_TYPE'
  exit 1
end

And invoke it like so:

$ env PODFILE_TYPE=development pod install

Also, is it possible to duplicate a build target from within a podfile? (via built in cocoapods functionality or with a script)

Take a look at the Xcodeproj API which powers CocoaPods: http://rubydoc.info/gems/xcodeproj/frames/Xcodeproj/Project

[dimaj]

You're awesome!

Yeah, I was using XcodeProj gem to do my post_install hook

Thanks guys!

[krzyzanowskim]

@kapin
[!] Unable to find a target named debug

[alloy]

@krzak If your app target isn’t actually called ‘debug’ then you cannot use it like that. In this case @Kapin used the label ‘debug’ to indicate that this is a ‘debug-only’ target, but it could have been called anything.

[krzyzanowskim]

ok ok, so I have something like this:

xcodeproj `TestProject`, 'Mac App Store' => :release, 'Test' => :debug

Is it possible to figure out that this :debug is 'Test' ?

[alloy]

Is it possible to figure out that this :debug is 'Test' ?

It’s not clear to me what you mean exactly. Did you mean the other way around? E.g. “is it possible to have CocoaPods figure out that the 'Test' target needs a :debug configuration”

[krzyzanowskim]

yes, this is what I want to ask @alloy ;) is it ?

[alloy]

While it might seem simple with a name like ‘test’ this means it would work only work automatically in some cases and not in others. This inconsistency will make it hard for users to understand and learn about this, which is why we chose to always default to :release (because that’s the safest for, e.g., AdHoc or AppStore builds), and allow the user to override this.

[krzyzanowskim]

Thanks. Anyway looks like great idea to implement something similar to rails, or rake itself like PODS_ENV and similar configuration like this:

group :development do
  pod 'Foo'
end

[alloy]

Yeah we do want that, but the real issue is with configuring Xcode projects to include certain pods in certain configurations only etc. We should have a few tickets for this, e.g. #731.