custom copy resources failing with 0.17.0.rc2

[incanus]

I'm testing out the new version with the MapBox spec and it's failing lint as below. This bit of the spec is related to first building a resources bundle, then copying it. The bundle is not available like normal resources since it's a secondary target in the Xcode project that needs to be built first. I worked out this method with some help on the mailing list, but I'm not sure why it's breaking.

Stack

   CocoaPods : 0.17.0.rc2
        Ruby : ruby 1.8.7 (2012-02-08 patchlevel 358) [universal-darwin12.0]
    RubyGems : 1.8.24
        Host : Mac OS X 10.8.2 (12C60)
       Xcode : 4.6 (4H127)
Ruby lib dir : /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ ec9fb10308b3e27c3abc13fd46d75744078d2536

Error

NoMethodError - undefined method `copy_resources_script_name' for #<Pod::Podfile::TargetDefinition label=Pods>
/tmp/CocoaPods/Lint/Pods/Local Podspecs/MapBox.podspec:31:in `post_install'
/Library/Ruby/Gems/1.8/gems/cocoapods-core-0.17.0.rc2/lib/cocoapods-core/specification/dsl/deprecations.rb:24:in `singleton_method_added'
/Library/Ruby/Gems/1.8/gems/cocoapods-core-0.17.0.rc2/lib/cocoapods-core/specification.rb:417:in `call'
/Library/Ruby/Gems/1.8/gems/cocoapods-core-0.17.0.rc2/lib/cocoapods-core/specification.rb:417:in `post_install!'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/installer.rb:382:in `run_post_install_hooks'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/installer.rb:381:in `each'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/installer.rb:381:in `run_post_install_hooks'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/installer.rb:379:in `each'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/installer.rb:379:in `run_post_install_hooks'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/user_interface.rb:107:in `message'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/installer.rb:378:in `run_post_install_hooks'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/installer.rb:111:in `generate_pods_project'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/user_interface.rb:46:in `section'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/installer.rb:106:in `generate_pods_project'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/installer.rb:86:in `install!'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/validator.rb:238:in `install_pod'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/validator.rb:205:in `perform_extensive_analysis'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/validator.rb:201:in `each'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/validator.rb:201:in `perform_extensive_analysis'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/validator.rb:69:in `validate'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/command/spec.rb:95:in `run'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/command/spec.rb:89:in `each'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/command/spec.rb:89:in `run'
/Library/Ruby/Gems/1.8/gems/claide-0.2.0/lib/claide.rb:535:in `run'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/lib/cocoapods/command.rb:36:in `run'
/Library/Ruby/Gems/1.8/gems/cocoapods-0.17.0.rc2/bin/pod:16
/usr/bin/pod:23:in `load'
/usr/bin/pod:23

[dulacp]

This is issue is impacting other specs like the HockeySDK-iOS.

I managed to find that the copy_resources_script_name method was removed in this commit. Hope it can help @irrationalfab to find another workaround. I will search too this afternoon.

[fabiopelosin]

The path is now accessible through:

def s.post_install(library) # library_representation replaces the old target installer
  script_path = library.copy_resources_script_name
end

I was not able to keep compatibility with 0.16. You can use a copy of the podspec updated but, please don't submit it to the specs repo until 0.17 is released as it would create issue in 0.16.

FYI the issues with the hooks are cause by a refactor introduced to prevent this kind of issue in future. Previously the hooks where using out internal class which are not stable yet. With the representations which are used now, we can control precisely the exposed interface.

[dulacp]

Thanks for giving us details, it's nice to understand the engineering decision behind the refactor.
@irrationalfab, do you think it'd be interesting to write a "transition guide from 0.16 to 0.17" ? If you think so, I'd be glad to give you a hand.

[fabiopelosin]

Having a transitioning guide (one for all the version) would be very helpful. I see that you are already familiar with the docs repo. So if this is something that you would like to work on please feel free to go ahead. I'm a bit busy to curate it atm but I can answer any question you have.

Btw let me know if you would like to join our Campfire.

[dulacp]

I will work on something for the transition! so I'll sure have a lot of question :) because this repository is new for me, but I like the way you've built it, so I'm reading the source code to understand the pieces and so far that's a great experience.

Btw I'd love joining your Campfire !

[fabiopelosin]

Invitation sent!