Could not access pods_project on post_install hooks when incremental_installation is enabled #8604

giginet · 2019-03-12T08:09:16Z

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

The text was updated successfully, but these errors were encountered:

sebastianv1 · 2019-03-12T16:27:29Z

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 · 2019-03-12T16:30:29Z

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

sebastianv1 · 2019-03-12T16:40:39Z

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 · 2019-03-12T16:52:15Z

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 · 2019-05-24T20:19:35Z

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

sebastianv1 · 2019-05-24T22:05:23Z

Why would you need to work with the installation cache?

mplorentz · 2020-08-14T14:10:21Z

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

diecalo · 2021-02-06T09:47:50Z

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:

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

bestswifter · 2022-07-03T09:01:18Z

The simplest solution I can find out is manually enable --clean-install if need in pre-install hook:

pre_install do |installer|
    # We can gather all hooks into single file/directory and check if it is updated.
    installer.clean_install = true
end

giginet mentioned this issue Mar 12, 2019

[WIP] Fix post_install hooks when incremental_installation is enabled. #8603

Closed

dnkoutso closed this as completed Mar 13, 2019

manajay mentioned this issue Jun 21, 2019

开启 Cocoapods 新选项，加快项目索引速度 | kemchenj kemchenj/kemchenj.github.io#42

Open

aaronraff mentioned this issue Dec 22, 2019

[cloud_firestore] Update README.md firebase/flutterfire#1563

Closed

This was referenced Apr 12, 2020

Fix long iOS build times enspyrco/crowdleague#19

Closed

Fix long iOS build times adventures-in/chat_app#84

Closed

IjzerenHein mentioned this issue Oct 27, 2020

[bare-expo] Get pods into a good state expo/expo#10812

Merged

Kudo mentioned this issue Aug 5, 2021

[ci] Fix broken workflows expo/expo#13931

Merged

sethfri mentioned this issue Nov 18, 2021

Pod install fails when using generate_multiple_pod_projects and incremental_installation spotify/XCRemoteCache#18

Closed

polac24 mentioned this issue Nov 21, 2021

[CocoaPodsPlugin] Support first-party caching for incremental install spotify/XCRemoteCache#19

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Could not access pods_project on post_install hooks when incremental_installation is enabled #8604

Could not access pods_project on post_install hooks when incremental_installation is enabled #8604

giginet commented Mar 12, 2019

sebastianv1 commented Mar 12, 2019

dnkoutso commented Mar 12, 2019

sebastianv1 commented Mar 12, 2019

dnkoutso commented Mar 12, 2019

nebiros commented May 24, 2019

sebastianv1 commented May 24, 2019

mplorentz commented Aug 14, 2020

diecalo commented Feb 6, 2021

bestswifter commented Jul 3, 2022

Could not access pods_project on post_install hooks when incremental_installation is enabled #8604

Could not access pods_project on post_install hooks when incremental_installation is enabled #8604

Comments

giginet commented Mar 12, 2019

Report

What did you do?

What did you expect to happen?

What happened instead?

CocoaPods Environment

Stack

Installation Source

Plugins

Podfile

Project that demonstrates the issue

sebastianv1 commented Mar 12, 2019

dnkoutso commented Mar 12, 2019

sebastianv1 commented Mar 12, 2019

dnkoutso commented Mar 12, 2019

nebiros commented May 24, 2019

sebastianv1 commented May 24, 2019

mplorentz commented Aug 14, 2020

diecalo commented Feb 6, 2021

bestswifter commented Jul 3, 2022