Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
giginet opened this issue Mar 12, 2019 · 6 comments

Comments

@giginet
Copy link

commented Mar 12, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Mar 12, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2019

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

@sebastianv1

This comment has been minimized.

Copy link
Collaborator

commented Mar 12, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2019

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.

@dnkoutso dnkoutso closed this Mar 13, 2019

@nebiros

This comment has been minimized.

Copy link

commented May 24, 2019

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

@sebastianv1

This comment has been minimized.

Copy link
Collaborator

commented May 24, 2019

Why would you need to work with the installation cache?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.