Downloader should not throw an error when installing #1577

Closed
Kapin opened this Issue Nov 11, 2013 · 6 comments

Projects

None yet

4 participants

@Kapin
CocoaPods member

Report

  • What did you do?

Upgraded to Google Analytics 3.0.2. Ran pod install. Stashed my change. Ran pod install again.

  • What did you expect to happen?

It should revert to the old version of the pod

  • What happened instead?

It crashed

Stack

   CocoaPods : 0.27.1
        Ruby : ruby 1.9.3p448 (2013-06-27 revision 41675) [x86_64-darwin12.4.0]
    RubyGems : 2.1.3
        Host : Mac OS X 10.9 (13A603)
       Xcode : 5.0.2 (5A3005)
Ruby lib dir : /Users/jkalpin/.rvm/rubies/ruby-1.9.3-p448/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ d7480a352d4135dc38aa18ef43a9dfd50b8edcf7

Podfile

platform :ios, '6.0'

workspace '***'
xcodeproj '***'
xcodeproj '***'

target :*** do
  xcodeproj '***'
  link_with 'iPhone Unit tests'

  pod 'AFNetworking', '2.0.2'
  pod '***', :path => '***'
  pod 'GoogleAnalytics-iOS-SDK', :git => 'https://github.com/mrbaker4/Google-Analytics-iOS-SDK-2.0beta4'
  pod 'KissXML', '5.0'
  pod 'CocoaAsyncSocket', '7.3.2'
  pod 'AGi18n', '0.0.1'
  pod 'TwilioSDK', '0.0.4'
  pod 'ISO8601DateFormatter', '0.7'
  pod 'TestFlightSDK', '2.0.2'
  pod 'ObjectiveRecord', '1.4.0'
  pod 'Base64', '1.0.1'

  target :KiwiUnitTest do
    pod 'Kiwi', '2.2.3'
  end
end

post_install do
  puts "*****"
  puts "Installing *** pods"
  `cd ***; bundle install; pod install | tee /dev/stderr`
  puts "Finished installing *** pods"
  puts "*****"
end

Error

TypeError - can't dup NilClass
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/lib/cocoapods/installer/pod_source_installer.rb:149:in `dup'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/lib/cocoapods/installer/pod_source_installer.rb:149:in `downloader'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/lib/cocoapods/installer/pod_source_installer.rb:101:in `download_source'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/lib/cocoapods/installer/pod_source_installer.rb:64:in `install!'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/lib/cocoapods/installer.rb:263:in `install_source_of_pod'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/lib/cocoapods/installer.rb:237:in `block (2 levels) in install_pod_sources'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/lib/cocoapods/user_interface.rb:73:in `titled_section'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/lib/cocoapods/installer.rb:236:in `block in install_pod_sources'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/lib/cocoapods/installer.rb:234:in `each'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/lib/cocoapods/installer.rb:234:in `install_pod_sources'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/lib/cocoapods/installer.rb:103:in `block in download_dependencies'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/lib/cocoapods/user_interface.rb:52:in `section'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/lib/cocoapods/installer.rb:101:in `download_dependencies'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/lib/cocoapods/installer.rb:87:in `install!'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/lib/cocoapods/command/project.rb:38:in `run_install_with_update'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/lib/cocoapods/command/project.rb:68:in `run'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/claide-0.3.2/lib/claide/command.rb:206:in `run'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/lib/cocoapods/command.rb:51:in `run'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/gems/cocoapods-0.27.1/bin/pod:19:in `<top (required)>'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/bin/pod:23:in `load'
/Users/jkalpin/.rvm/gems/ruby-1.9.3-p448/bin/pod:23:in `<main>'
@Kapin
CocoaPods member

Deleting Pods directory seems to have fixed it. Regardless, this shouldn't happen.

@fabiopelosin
CocoaPods member

So basically to avoid checking every time if the attribute of a spec is nil, we delegate that work to the linter and assume that they all work correctly.

I haven't never found the time to document it, but to avoid issues like these I planned to do a quick lint of the specs (failure only on errors and not on warnings) before installing them. Doing in the resolution is likely to lead to a significant performance hit as the specs might bee too many.

@Kapin
CocoaPods member

This might be related to upgrading to a pod with a :git tag specified and then reverting back to the one with the tag specified. Still not 100% sure on that either.

@Kapin Kapin assigned CocoaPodsBot and unassigned CocoaPodsBot Mar 29, 2014
@siuying

@Kapin I cannot reproduce this issue with current version by:

  1. Install the podspec above
  2. Change 'Google Analytics' to '3.0.2' and pod install
  3. stash the changes
  4. pod install again
@CocoaPodsBot CocoaPodsBot was assigned by Kapin Mar 29, 2014
@CocoaPodsBot

@neonichu closed with reason "Cannot be reproduced"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment