Cocoapods: Could not access pods_project on post_install hooks when incremental_installation is enabled

[giginet]

• [x] I've read and understood the CONTRIBUTING guidelines and have done my best effort to follow.

Report

What did you do?

When incremental_installation option is enabled, installer#pods_project returns nil in post_install hook.

install! 'cocoapods',
         :generate_multiple_pod_projects => true,
         :incremental_installation => true

target 'MyApp' do
  use_frameworks!

  pod 'Result'
end

post_install do |installer|
  installer.pods_project.targets.each do |target|
    # do something
  end
end

Before submitting this PR, (1.7.0beta.2) this Podfile raises following errors.

[!] An error occurred while processing the post-install hook of the Podfile.

undefined method `targets' for nil:NilClass

/Users/giginet/myproject/Podfile:12:in `block (2 levels) in from_ruby'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/cocoapods-core-1.7.0.beta.2/lib/cocoapods-core/podfile.rb:179:in `post_install!'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/cocoapods-1.7.0.beta.2/lib/cocoapods/installer.rb:835:in `run_podfile_post_install_hook'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/cocoapods-1.7.0.beta.2/lib/cocoapods/installer.rb:823:in `block in run_podfile_post_install_hooks'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/cocoapods-1.7.0.beta.2/lib/cocoapods/user_interface.rb:145:in `message'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/cocoapods-1.7.0.beta.2/lib/cocoapods/installer.rb:822:in `run_podfile_post_install_hooks'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/cocoapods-1.7.0.beta.2/lib/cocoapods/installer.rb:309:in `block in create_and_save_projects'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/cocoapods-1.7.0.beta.2/lib/cocoapods/user_interface.rb:64:in `section'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/cocoapods-1.7.0.beta.2/lib/cocoapods/installer.rb:290:in `create_and_save_projects'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/cocoapods-1.7.0.beta.2/lib/cocoapods/installer.rb:281:in `generate_pods_project'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/cocoapods-1.7.0.beta.2/lib/cocoapods/installer.rb:159:in `install!'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/cocoapods-1.7.0.beta.2/lib/cocoapods/command/install.rb:51:in `run'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/claide-1.0.2/lib/claide/command.rb:334:in `run'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/cocoapods-1.7.0.beta.2/lib/cocoapods/command.rb:52:in `run'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/cocoapods-1.7.0.beta.2/bin/pod:55:in `<top (required)>'
/Users/giginet/.rbenv/versions/2.5/bin/pod:23:in `load'
/Users/giginet/.rbenv/versions/2.5/bin/pod:23:in `<top (required)>'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/site_ruby/2.5.0/bundler/cli/exec.rb:74:in `load'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/site_ruby/2.5.0/bundler/cli/exec.rb:74:in `kernel_load'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/site_ruby/2.5.0/bundler/cli/exec.rb:28:in `run'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/site_ruby/2.5.0/bundler/cli.rb:463:in `exec'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/site_ruby/2.5.0/bundler/cli.rb:27:in `dispatch'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/site_ruby/2.5.0/bundler/cli.rb:18:in `start'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/bundler-1.17.3/exe/bundle:30:in `block in <top (required)>'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/site_ruby/2.5.0/bundler/friendly_errors.rb:124:in `with_friendly_errors'
/Users/giginet/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/bundler-1.17.3/exe/bundle:22:in `<top (required)>'
/Users/giginet/.rbenv/versions/2.5/bin/bundle:23:in `load'
/Users/giginet/.rbenv/versions/2.5/bin/bundle:23:in `<main>'

What did you expect to happen?

We should access installer.pods_project in this situation.

What happened instead?

Whenincremental_installation is enabled, CocoaPods doesn't generate Pods.xcodeproj when there are nothing changes between cached project.
In this case PodsProjectGeneratorResult#project become nil.

So installer#pods_project also become nil.

CocoaPods Environment

Stack

   CocoaPods : 1.7.0.beta.1
        Ruby : ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin17]
    RubyGems : 3.0.3
        Host : Mac OS X 10.14.2 (18C54)
       Xcode : 10.1 (10B61)
         Git : git version 2.19.1
Ruby lib dir : /Users/giginet/.rbenv/versions/2.5.1/lib
Repositories : 
               master - https://github.com/CocoaPods/Specs.git @ 2084ff831cbe8115107fab319825e382ea2d33b6

Installation Source

Executable Path: /Users/giginet/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/bin/pod

Plugins

cocoapods-deintegrate : 1.0.3
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.1.0
cocoapods-trunk       : 1.3.1
cocoapods-try         : 1.1.0

Podfile

require 'pry'

workspace 'CocoaPodsSandbox.xcworkspace'

install! 'cocoapods',
         :generate_multiple_pod_projects => true,
         :incremental_installation => true

target 'CocoaPodsSandbox' do
  use_frameworks!

  pod 'Result'
end

post_install do |installer|
  installer.pods_project.targets.each do |target|
  end
end

Project that demonstrates the issue

none

[sebastianv1]

When the incremental_installation option is enabled, it is possible that installer#pods_project can be nil if we determined that it did not need to be regenerated for that installation. As a result of this change, we provided installer#generated_projects (and also installer#generated_pod_targets & installer#generated_aggregate_targets)

[dnkoutso]

That is correct. ^ @sebastianv1 can we still not set the ref or have we not "opened" the project for speed?

[sebastianv1]

We _could_ just open the container project, but I think that sets a bad precedent since others may have similar complaints about other individual projects being nil which would then require us opening all projects every installation (very inefficient for large projects).

Also post install hooks should only need to operate over the changed set of projects or targets to apply whatever changes are needed. The only case where this fails is if someone adds a post install hook to a specific pod that won't be regenerated during the next installation, in which --clean-install would be required. I'm not sure if this is possible, but if we can determine that the post install hook has changed, then we could force a full install?

[dnkoutso]

I dont think we want to get in that mode to detect the post_install hook. @giginet I don't think there is a change we want to make here.

[nebiros]

I see that we can work with installation_cache field, but it's private, any chance to make it public?

[sebastianv1]

Why would you need to work with the installation cache?

[mplorentz]

For anyone else who comes across this issue, I was able to work around this in my post_install hook using Ruby's Safe Navigation Operator (&) like this:

post_install do |installer|
  installer.pods_project&.targets&.each do |target|
    # do something
  end
end

[dcarra01]

In my case, using the Safe Navigation Operator does not work

I have this configuration in Podfile:

platform :ios, '12.2'
install! 'cocoapods',
:generate_multiple_pod_projects => true,
:incremental_installation => true

And the this code below does not make effect:

post_install do |installer|
installer.pods_project&.targets&.each do |target|
target.build_configurations.each do |config|
config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '12.2'
end
end
end

If I remove the first configuration of multiple pod projects and incremental installation, the code above works as expected.