Cocoapods: Local Podspecs doesn't get updated

[rivera-ernesto]

I noticed that modified local podspecs (:path => '../Local/Path' in Podfile) stored in Pods/Local Podspecs don't get properly updated by $ pod install.

CocoaPods should either:

• Check for newer versions of the local podspec and overwrite them in Pods/Local Podspecs.
• Sym link local podspecs so they are always up to date.

[nikolaykasyanov]

:thumbsup:

[fabiopelosin]

I thought that there was an issue open about this but I was not able to find it. :+1:

[rivera-ernesto]

Neither did I ;)

[fabiopelosin]

ehheeh :beers:

[CocoaPodsBot]

Issue has been confirmed by @neonichu

[rivera-ernesto]

Well the bot found it. Curious about how does it work.

[meroon]

I am seeing this issue with 0.33.1. I've had to update our build box to remove Podfile.lock before running pod install. I've also instructed our devs to manually remove the lock file if they encounter this error with a local development pod.

Guidance on how to manage private, local development pods would be incredibly helpful.

Cheers!

[segiddins]

Instead of rming the lock file, you should be able to run pod update $LocalPodspecName to only update that one local spec

[mx4492]

Instead of rming the lock file, you should be able to run pod update $LocalPodspecName to only update that one local spec

This does not address our scenario (which might be similar to @meroon) because we do not know a priori the names of the pods which need to be updated. In a bit more detail -

• Our internal libraries are packaged as pods, but they are not published to a pod repository. These are stated as :git => and :tag => references in the project's Podfile.
• The CI machine checks out project and does a pod install to reproduce the environment stated in Podfile.lock. This pod install seems to fails if any of our private git pods have had their tags updated (note these internal libraries have dependency links between them).
• Since we do not know the names of the pods that could have been updated, and there are multiple number of them, we just remove the Pods directory before each build. This works, but leads to an unnecessary delay in each build as the Pods hierarchy is reconstructed.

BTW, the pod update foo solution does not work if you have a pod with subspecs (i.e. say foo has subspecs 1, 2 and 3, and your podfile only includes pod foo/1 and pod foo/3, then pod update foo does not solve this issue if the tags to the foo are changed).

Also, @meroon removing the Podfile.lock is a potentially dangerous solution - you might get different versions on your development and build machines. Removing the Pods directory is more expensive but safer.

[segiddins]

The idea of pod install is that the exact source that is installed should not change unless the Podfile itself it updated.
Where are you updating tags that you expect installed source to change? In the Podfile? Additionally, we recommend the use of private pod repositories if you have a (large) dependency tree of private specs.

[mx4492]

Where are you updating tags that you expect installed source to change? In the Podfile?

Yes. That's the expected way, right?

[segiddins]

@mx4492 please open up a separate issue, and try to reproduce in as small a test case as possible?

[mx4492]

@segiddins I believe there is already a reproduction (https://github.com/CocoaPods/CocoaPods/issues/1470).

From poking around, it seems that podspecs for :git references somehow make their way into the "Local Podspecs" directory, and the specs in this folder are left stale during some operations (https://github.com/CocoaPods/CocoaPods/issues/1749).

[mx4492]

A detailed scenario that way I see it playing out:

• Originally pod "Foo" (which is specified via the :git =>, :tag => mechanism) is at version (== tag) 1.0.0.
• Developer Alice updates "Foo" to 2.0.0, and checks in the changes to both Podfile and Podfile.lock.
• Developer Bob merges Alice's changes. At this point both his Podfile and Podfile.lock state 2.0.0, however the specification in his local Pods/Local Podspecs folder still states 1.0.0

In this scenario, flow reaches resolver.rb, line 155

set.required_by(dependency, dependent_spec.to_s)

with the following values

spec = #<Pod::Specification::Set::External for `Foo' with required version `1.0,0' available at `'>
dependency = <Pod::Dependency name=Foo requirements== 2.0.0 external_source={:git=>"[email protected]:foo/Foo", :tag=>"2.0.0"}>
dependent_spec = Podfile

which blows up at Core/lib/cocoapods-core/specification/set.rb, line 64 with

    if acceptable_versions.empty?
      message = "Unable to satisfy the following requirements:\n\n"

I would attach a patch, but I'm not sure where to fix. I would think that Pod::Specification::Set::External#required_by should always succeed, but that seems rather crude.

[AliSoftware]

@segiddins @mx4492 I just wrote a detailed answer here (that I shall transform into a page in Guides someday, btw) to help understand the expected usage between pod install vs pod update OnePod vs. pod update, maybe that will help here on the subject ?

This does not address our scenario (which might be similar to @meroon) because we do not know a priori the names of the pods which need to be updated.

You can use pod outdated for that, which will list all the pods that could be updated via pod update XXX according to the pods and versions you are using in your project.

[orta]

IMO dev pods should be an exception here.

I'd expect that if I did a pod install with a local pod it would do the equivalent to pod update XX and update to be whatever version the Podspec is. My main argument here is that the files will always be up to date because they're sym-linked but ignoring changes to the Podspec doesn't make sense.

[neonichu]

+1 to @orta's opinion.

[davidquon]

:+1: to @orta's opinion as well.

[fabiopelosin]

Moving to https://github.com/CocoaPods/CocoaPods/issues/2278 as the podspec of local Pods don't need to be copied.

[afshin-hoseini]

I faced this issue and found my own solution since others didn't help me.
In demo project's navigation under Pods/Products, right click the .framework files and select show in finder. Then remove them. After that build the library project and then perform pod update for demo project. Then quit the xcode and reopen it and perform clean and then build.

Briefly, remove xcode's DerrivedData folder.