Cocoapods: Change in pod selection with 1.4.0 (was OK with 1.4.0rc1)

[mwoollard]

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

Report

What did you do?

pod install

What did you expect to happen?

pod from my private specs repo to be installed

What happened instead?

pod that happened to have the same name was picked from the main public specs repo even though my private repo was first in Podfile.

Notes

This change seems to have been introduced by 1.4.0 as I didn't have this problem with 1.4.0rc1. If I explicitly specify a version for my private pod then pod install finds and uses it. If I don't it seems it now uses the highest version across spec repos rather than taking the one found in the first specified repo. Whilst I could change the name of my pod it would seem that this is incorrect behaviour and naming of a private pod is now fragile and dependent on no one choosing the same name in the master public repo.

It would appear that:

Fix resolution when multiple sources provide the same pods, and there are
(potential) dependencies between the sources.
Samuel Giddins
#7031

would be the change that had this effect?

Could the team confirm that this change in behaviour is not intended as I see it leading to lots of problems as private repo selection can now be broken by subsequent pods being published in the master repo.

Any workaround other than renaming my pod or reverting to rc1 ?

Thanks!

CocoaPods Environment

Stack

   CocoaPods : 1.4.0
        Ruby : ruby 2.3.3p222 (2016-11-21 revision 56859) [universal.x86_64-darwin17]
    RubyGems : 2.6.14
        Host : Mac OS X 10.13.2 (17C205)
       Xcode : 9.2 (9C40b)
         Git : git version 2.14.3 (Apple Git-98)
Ruby lib dir : /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib
Repositories : master - https://github.com/CocoaPods/Specs.git @ 1bdd0d5636e035eb1e19a0ada15aeff306d4334a
               mwoollard - https://github.com/mwoollard/specs.git @ e0daa30356cb63fa2b746218c8460ccf23645cbb
               mwoollard-1 - https://github.com/mwoollard/erg_core.git @ fe3135ecf142ee779f80459c368bc795eb065438
               urbanthings - [email protected]:urbanthings/podspecs.git @ 7deb5ca6bf8b77940d23cd40f9dd300f76e386f8

Installation Source

Executable Path: /usr/local/bin/pod

Plugins

cocoapods-deintegrate : 1.0.2
cocoapods-plugins     : 1.0.0
cocoapods-search      : 1.0.0
cocoapods-stats       : 1.0.0
cocoapods-trunk       : 1.3.0
cocoapods-try         : 1.1.0

Podfile

source 'https://github.com/mwoollard/specs.git'
source 'https://github.com/CocoaPods/Specs.git'

use_frameworks!

abstract_target 'Shared' do

    pod 'Core'
    pod 'RxSwift'
    pod 'Map'

    target 'AirQuality' do
        platform :ios, '10.0'
    end

    target 'AirQualityTests' do
        platform :ios ,'10.0'
    end

end

[dnkoutso]

Thanks for the report, currently no workaround we need to investigate, specifying the :source next to pod 'Core' should also probably do it.

[dnkoutso]

@mwoollard Providing a clear sample app would help a lot, although this might be more difficult as it requires the same pod published in more than one repo?

[mwoollard]

Thanks for quick response and :source suggestion.
I can probably set something up in the way of complete demo project sometime this week if that'd help.

[dnkoutso]

It would most certainly help!

[mwoollard]

See https://github.com/mwoollard/app-7354 - let me know if any questions !

[mwoollard]

I can confirm that specifying the pod with:

pod 'Core',  :source => 'https://github.com/mwoollard/specs.git'

is a workaround that forces selection from the correct specs repo. However I was unaware of this as an option of the 'pod' statement as it doesn't appear to be documented in the Podfile Syntax Reference. Maybe good to do so?

[dnkoutso]

+1 certainly, want to make a PR for it?

[mwoollard]

Tracked down where this documentation comes from so will take a look.

[mwoollard]

This issue also effects dependencies specified in podspec files as I have a number of inter-dependent components in my private specs repo. Only workaround I've found for this case is to tie the dependency to a limited version range which is not ideal but at least have things working with 1.4.0. Assuming its the same underlying problem so not creating a new issue.

[dnkoutso]

It's most likely the same issue, we are currently working on Swift Static Library support so once some time is freed we can take a look, apologies for the problem, you are being hit by this because the same pod is published in multiple sources which is not common, but yes it is a bug.

[mwoollard]

Static Swift Library support will make big difference to us so agree with your priorities !

[segiddins]

I dont think this is a bug -- we've resolved to the highest version possible

[dnkoutso]

@mwoollard thoughts on this? We might want to close if it works as intended.

[nikano1991]

I'm in a situation very similar to @mwoollard. Let me describe it to make things clearer.

I have a project that uses pods from two different sources (private source and master), they are specified like this in the podfile:

source 'url_to_private_specs_repo'
source 'https://github.com/CocoaPods/Specs.git'

Lets suppose I'm importing a pod named SideMenu, and there is a pod with that name in both repositories (they are different, but have the same name) and the one in the master repository has a higher version number.

In version 1.4.0.rc.1 the order of the sources would define the priority in which they are resolved, while in version 1.4.0 (and 1.5.0) they are resolved to the highest version number.

In version 1.4.0.rc.1 it uses the SideMenu of the private specs repo
In version 1.4.0 (and 1.5.0) it uses the SideMenu of the master

For the podfile it can be solved using:

pod 'SideMenu',  :source => 'url_to_private_specs_repo'

As it has already been discussed in this thread.

However, in the podspec there is no such option as source (as far as I'm aware of).
It is possible to upload a new podspec by doing:

pod repo push my-specs my-pod.podspec --sources=url_to_private_specs_repo,master

This way, in version 1.4.0.rc.1, you could specify the priority of the sources when resolving dependence, but since in version 1.4.0 (and 1.5.0) they resolve to the hightest version, there is no way to do so.

Is this the intended behavior as @segiddins pointed out? If so, should a source option be added for podspecs as it is done in podfile?

Sorry for my verbose explanation, but I really wanted to make the problem really clear and precise.

[nikano1991]

Any comments on this @dnkoutso @segiddins @mwoollard ?

[segiddins]

If so, should a source option be added for podspecs as it is done in podfile?

this has been discussed before, it won't happen

Is this the intended behavior as @segiddins pointed out

I think the root of the issue here is that there are 2 equally valid behaviors, and picking either 1 would appear to be a bug to people expecting the other :/

[nikano1991]

Hi @segiddins,

Thanks for answering :) Here are my thought about what you said:

this has been discussed before, it won't happen

ooow :(
Can you point me to the thread discussion (if there is one), I don't see how adding this option would be a bad thing

I think the root of the issue here is that there are 2 equally valid behaviors, and picking either 1 would appear to be a bug to people expecting the other :/

Maybe you right, but I don't see the 2 equally valid behaviors.
Now people would need to make sure to pick names for their private pods that do not collide with names in the Master pods repository so to avoid situations as the one I described before.

Besides, in the way it is done right now, it is possible that a PodSpec that's was working at some moment in the past, stops working only because someone added a new pod (or updated a pod) to the public pod specs repo. Sounds dangerous to me... :S

[jdbandoni]

If so, should a source option be added for podspecs as it is done in podfile?

this has been discussed before, it won't happen

Is this the intended behavior as @segiddins pointed out

I think the root of the issue here is that there are 2 equally valid behaviors, and picking either 1 would appear to be a bug to people expecting the other :/

Hi @segiddins, I have some doubts about this. In order to clarify, we suppose this situation:

I have a private pod name Example and currently doesn't exists a public pod called "Example". For some reason, somebody creates a public pod with that name and generates the version 10.0.0. This version is probably greater, consequently, I don't touch my code and it will be failed without any reason because of the new dependency downloaded. I think this scenario is not nice. Why doesn't prioritize the source order instead the greatest version number? This works like this in cocoapods < 1.4.

Thank you!