Cocoapods: Add `pod update [podname]` command

[nickynick]

Existing pod update only allows you to update all pods at once. But sometimes you don't need that, you just want to get the latest version of the specific pod. Right now this involves nuking its directory in Pods, stripping it from Podfile.lock and running pod install. Quite annoying :)

Thus, it would be nice to be able to supply a pod name (or, possibly, a list of names) to pod update to limit its updating scope.

[jonah-williams]

Agreed, this would be nice to have. Do you image this would work like bundle update <gem> and try to update the dependencies of the updated pod as needed as well?

[nickynick]

Well, this is a bit tricky. I personally thought about updating the given pod only, because this is what I would expect to happen. This command is like saying "please ignore the lock entry for this pod and give me its latest version".

However, I see how others may expect it to update the dependencies as well. Need more opinions :)

[fabiopelosin]

Too keep things simple, for the first iteration, I would update only the given pod. I think that if the dependencies are not specified in the Podfile the user expects them to update. If they are specified in the Podfile on the other it could surprise some if they are updated.

[jonah-williams]

That's a reasonable place to start, as long as pods can handle that the resulting set of dependencies may not be valid. That's a possible with any approach we take though, just like when first installing pods there may be incompatible dependencies between components.

[nickynick]

Yeah, I guess the case of unresolvable dependencies here doesn't differ from those that may happen with pod install or pod update, so this hopefully will be pretty straightforward.

[shekibobo]

Is anyone working on this feature? I've seen requests and discussion, but no code. I've done some inspection and it looks like this might be a significant undertaking, but I'm wondering if anyone has put any thought into the implementation yet.

From what I can see, it looks like it would require parsing arguments from the update command (in /lib/cocoapods/command/project.rb?), and then passing that array of pods down the line (Installer -> Analyzer). Looks like most of the fun would probably happen in the Analyzer.

FWIW, I agree that pods in the Podfile.lock but not in the Podfile should be updated if it is a dependency of the updated file. However, we would need to consider the condition where pods share an unlisted dependency, resolving these updates as necessary, and maybe notifying when a pod is not fully updated due to a restriction from another pod (i.e. it can update to a later version, but not the latest version). I believe Bundler will fail an update if the pod specified can't be updated because of a version restriction on a shared/listed dependency, displaying the dependency hierarchy from the Gemfile.lock.

I'm interested in helping out with this feature if it's not already being worked on, but my familiarity with the codebase is pretty limited at the moment.

[fabiopelosin]

Is anyone working on this feature? I've seen requests and discussion, but no code. I've done some inspection and it looks like this might be a significant undertaking, but I'm wondering if anyone has put any thought into the implementation yet.

Not to my knowledge.

From what I can see, it looks like it would require parsing arguments from the update command (in /lib/cocoapods/command/project.rb?), and then passing that array of pods down the line (Installer -> Analyzer). Looks like most of the fun would probably happen in the Analyzer.

Yes, the list should be passed down to the Resolver.

FWIW, I agree that pods in the Podfile.lock but not in the Podfile should be updated if it is a dependency of the updated file. However, we would need to consider the condition where pods share an unlisted dependency, resolving these updates as necessary, and maybe notifying when a pod is not fully updated due to a restriction from another pod (i.e. it can update to a later version, but not the latest version). I believe Bundler will fail an update if the pod specified can't be updated because of a version restriction on a shared/listed dependency, displaying the dependency hierarchy from the Gemfile.lock.

To be clear, I assume that you are referring to a dependency of a Pod which is unlisted in the Podfile? I'm of the opinion that if the user didn't specify it in the Podfile is not used and we can update. However, we can't update when the user did specify it in the Podfile and to update a given Pod that dependency would need to be updated. Printing the dependency tree would be awesome.

I'm interested in helping out with this feature if it's not already being worked on, but my familiarity with the codebase is pretty limited at the moment.

Awesome, don't worry about familiarity with the code base as I can provide support in that regard. If you do please open a pull request as soon as you start working on it.

As a starting point I strongly suggest to get familiar with the bundler's resolver.

[arctouch-josefreitas]

+1

[lancep]

This would be really nice to have!

[danpe]

+1

[davidquon]

:+1:

[shekibobo]

I just want to note that I've been too busy lately to even consider tackling this feature, so if anyone else feels like trying, go for it.

[NachoSoto]

:+1:

[akitsukada]

+1

[Leandros]

+1

[jemmons]

+:100:

[kejinlu]

+10086

[Whirlwind]

+10086

[akitsukada]

+1

[neoneye]

+1

[jeffdav]

+1

[getaaron]

Would it be easier to just add a new command?

$ pod update-bundle <bundle_name>

This could simply do what we're all doing manually:

1. Delete the pod (and any orphaned dependency pods) from Pods/
2. Delete references to the deleted pods from Podfile.lock
3. Run pod install

Before making any changes, it would need to make sure there are no uninstalled pods already listed in the Podsfile (to avoid the side effect of those getting installed too).

I know very little about the implementation of CocoaPods, so this might be a bad idea for some reason I haven't thought of - I'm just brainstorming.

[cipherCOM]

One possible solution for now to update only a single pod would be:

Remove specific pod from Podfile
pod install
Re-add specific pod to Podfile
pod install

A bit messy but does the job just right. Nevertheless +1 also from me to get this behavior directly with pod update <pod>

[fabiopelosin]

I would prefer to implement this feature in the proper way and I expect that it will come soon. The proposed band aid solutions in my opinion are not suitable for CocoaPods and could have been developed as plugins. However at this point in time I think that, even though they are pretty simple, the time spent implementing this workaround is not worth it.

[CocoaPodsBot]

Issue has been confirmed by @neonichu

[mrackwitz]

I have read a bit into bundler as suggested by @irrationalfab, how it is solved there and in the implementation of CocoaPods. I'm sure, I can soon create pull-request with a solution for this one.

[fabiopelosin]

@mrackwitz Nice!

[NachoSoto]

:boom:

[getaaron]

[Isuru-Nanayakkara]

Yes, please! I need this feature so bad because I sometimes change the code in 3rd party libraries to suit my needs and if I want to install another pod or do an update, I'm screwed because all of those changes get replaced!

[AliSoftware]

Isn't it already implemented?

I can du pod update AFNetworking on my project which will only update AFNetworking and won't update other pods, keeping them locked to their version defined in the Podfile.lock.

[Isuru-Nanayakkara]

@AliSoftware Hi, is it possible to do the same with pod install to install an individual pod?

[AliSoftware]

@Isuru-Nanayakkara Yes.

To be clear, here is the intended usage of pod update vs. pod install (which is inspired from bundler in the RubyGems world):

Detailed presentation of the commands

pod install

This is to be used every time you edit your Podfile to add a new pod to it (or remove one from it).

• Every time the pod install command is run and it downloads and install new pods, it writes the version that it has installed, for each pods, in the Podfile.lock file. This file is intended to keep track of the installed version of each pod and to _lock_ those versions
• When you run pod install, it only resolve dependencies for pods that are not already listed in the Podfile.lock.
  
  
  
  • For pods that are listed in the Podfile.lock, it downloads the explicit version listed in the Podfile.lock without trying to check if there is a newer version
  
  
  • For pods that are not listed in the Podfile.lock yet, it searches for the version that matches what is described in the Podfile (like in pod 'MyPod', '~>1.2')
  
  

pod outdated

When you run pod outdated, CocoaPods will list all pods that have newer versions that the ones listed in the Podfile.lock (the versions currently installed for each pod) and that could be updated (as long as it matches the restrictions like pod 'MyPod', '~>x.y' set in your Podfile)

pod update

When you run pod update SomePodName, CocoaPods will try to find an updated version of the pod SomePodName, without taking into account the version listed in Podfile.lock. It will update the pod to the latest version possible (as long as it matches the version restrictions in your Podfile).

If you run pod update without any pod name, CocoaPods will update every pod listed in your Podfile to the latest version possible.

Intended usage

With pod update SomePodName, you will be able to only update a given pod, namely check for a new version, for an update. Whereas pod install won't try to update versions of pods that already have been installed.

Normally, when you add a pod to your Podfile, you would run pod install, not pod update, to install this new pod without risking to update existing pod in the same process.
You will only use pod update when you want to update the version of a specific pod (or all the pods).

Benefits & Scenario Example

If you are the kind of people that don't commit the Pods folder into your shared repository, don't forget to at least commit & push your Podfile.lock file. This file must always be pushed to the repository.

• If user1 creates a project and uses it with some pods A,B,C, he will create a podfile with those pods and run pod install which will install pods A,B,C say all in version 1.0, because they are all in version 1.0 at that time. The Podfile.lock will keep track of that and note that A,B and C are each installed as version 1.0.
• Later, user1 wants to add a pod D into its Podfile. He should thus run pod install afterwards, so that even if a version 2 of pod B has been released since his first pod install, his project will keep using version 1, because he just want to add pod D without risking to update pod B unexpectedly.
• Then user2, who never worked on the project before, starts kicking in and want to participate. He clones the repository then use pod install. This will guaranty him that he will get the exact same pods with the exact same versions that user1 was using. Even if pod C has been updated to version 2 since (but the project's code haven't been tested with this version 2 yet), user2 will get the pod C in version 1 because that's what is registered is Podfile.lock. pod C is _locked_ to version 1 by the Podfile.lock (hence the name of this file)
• Later, user1 wants to check if there are any updates available for the pods. He runs pod outdated which will tell him that both pods B and C have a version 2 released. user1 want to update pod B, but not pod C, so he will run pod update B which will install B version 2 (and update the Podfile.lock accordingly) but will keep pod C in version 1.

---

_@irrationalfab I should probably transform this comment into a page in the Guides, where could I put this?_

[segiddins]

:+1: @AliSoftware!

[Whirlwind]

$ pod outdated
The following updates are available:
- ASIHTTPRequest 1.8.1-tbhd -> 1.8.2
- CocoaLumberjack 1.6.5.1 -> 1.9.0
- CocoaSecurity 1.2.2 -> 1.2.4
- JSONKit 1.4-tbhd -> 1.6-marcDown
- MTDates 0.11.0 -> 0.12.0
- munionSDK 1.2-tbhd -> 1.3.0-build-4
- ObjcAssociatedObjectHelpers 1.1.2 -> 1.2.1
- OLImageView 1.3.1 -> 1.3.2
- SBJson 1.0-tbhd -> 4.0.1
- UIAlertView+Blocks 0.8 -> 0.8.1
➜  $ pod update CocoaSecurity
Analyzing dependencies
Downloading dependencies
Using AKSegmentedControl (1.0.4)
Using ASIHTTPRequest (1.8.1-tbhd)
Using AlipaySDK4iPad (2.0.1)
Using CocoaLumberjack (1.6.5.1)
Using CocoaSecurity (1.2.2)
Using DACircularProgress (2.2.0)
Using GDataXMLNode (1.0.0)
Using HPGrowingTextView (1.1)
Using JSONKit (1.4-tbhd)
Using MAZeroingWeakRef (1.0)
Using MBProgressHUD (0.8)
Using MTDates (0.11.0)
Using MWPhotoBrowser (1.4.0)
Using NSData+Base64 (1.0.0)
Installing NSDate-Extensions HEAD based on 0.0.1 (was HEAD based on 0.0.1)
Using OLImageView (1.3.1)
Using ObjcAssociatedObjectHelpers (1.1.2)
Using OpenSSL (1.0.1)
Using PSTCollectionView (1.2.1)
Using Reachability (3.1.1)
Using RegexKitLite (4.0)
Using SBJson (1.0-tbhd)
Using SDWebData (1.1-tbhd)
Installing SDWebImage HEAD based on 3.6 (was HEAD based on 3.6)
Using SFHFKeychainUtils (0.0.1)
Using SVProgressHUD (1.0)
......

It seem that the CocoaSecurity update fail( still 1.2.2), and other pods seem to be updated?

I test on cocoapods v0.33.1.

[segiddins]

@Whirlwind we have separate issues for HEAD pods updating when they shouldn't. https://github.com/CocoaPods/CocoaPods/issues/2135

[Whirlwind]

but the CocoaSecurity update fail( still 1.2.2)

[Whirlwind]

I found the pod update [podname] not work!!

[orta]

that should get into a guide somehow @AliSoftware , make an issue with the markdown on guides ^

[AliSoftware]

@orta already done, see the issue referenced just above your comment :wink:

[orta]

too quick, good show sir.

[onmyway133]

+1

[allaire]

This is not working for me on --pre version

[orta]

@allaire can you please make a new issue with example output please ( use --verbose)

[johnrogers]

This is an old thread, however still seems to be visited frequently as a means to find an answer to this.

We ran into an issue where our CI running pod install via Fastlane would not update to the latest version of the pod (under development, pointing to the develop branch of the pod).

We found that this issue began to arise when we removed Podfile.lock from source control. Upon re-adding it, pod install recognises that the hashes have changed and always correctly updates the pod. If you're having issues with the Fastlane cocoapods step, make sure Podfile.lock is checked in and up-to-date in the commit you're building from to point to the commit of the Pod you'd like to use.

Hope this is helpful to someone! :)

[getaaron]

@johnrogers I found it helpful to add a Podfile.lock check in my Fastfile:

  private_lane :check_for_podfile_lock_changes do
    next unless Actions.sh("git status --porcelain").include? "Podfile.lock"
    UI.error "Looks like `pod install` modified Podfile.lock."
    UI.error "This can happen if you committed a change to Podfile but didn't also commit all of the changes to Podfile.lock."
    UI.error "Try running:"
    UI.command "pod install --repo-update"
    UI.error "Then commit the Podfile.lock changes locally, and retry."
    UI.user_error! "Aborting since the Podfile.lock change is unexpected."
  end