Cocoapods: Do `pod install` has to run `pod repo update` always?

[manuyavuz]

Hi,

Currently when pod install command runs, it always does a repo update.

pod help says the following:

+ install        Install project dependencies to Podfile.lock versions

I guess it does not have to perform a repo update if Podfile.lock and Podfile does not include changes. I now there is a --no-repo-update option, however most users just won't use it by default.

As master repo getting bigger and bigger, pod repo update takes more time, which could slow down development speed, especially for pod lib users who have to do pod install everytime they add a source file to their project.

Can we ignore updating repos by default if podfile does not include changes?

[segiddins]

It's not a terrible idea, but I do think there might be edge cases where this could break things, especially if there are development pods installed.

[neonichu]

There's no way to know if an existing podspec hasn't changed, so we definitely can't make any assumptions about repo updates.

[manuyavuz]

@neonichu I think we can assume that podspec for a specific version will not ever change because trunk forces a new version for any change in podspec, right?

If that's the case, I think we can trust on the versions existing in the Podfile.lock and perform an update only if any version constraint in the Podfile does not agree with the constraints in the Podfile.lock file.

[orta]

I think we also put a SHA of each Podspec in the Podfile.lock which we could use to detect changes there

[neonichu]

@manuyavuz trunk is not the only spec repo that exists

[neonichu]

@orta but to do that, we would first need to download the new specs :)

[manuyavuz]

@neonichu, does current implementation check for each pod if their SHA has changed after repo update and re-install changed ones?

[segiddins]

Yes.

[manuyavuz]

Umm, then I think the description in pod help is not fully true because it specifically says _"Install project dependencies to Podfile.lock versions"_.

If that's the current policy, my proposal wouldn't work. However I feel that pod install should not update a previously installed pod at all. It should be only responsible from installing non-existing pods or pods that locked version is not satisfying constraint in the Podfile anymore. To update a previously installed dependency, user should explicitly do a pod update.

For cases where version is not changed but the podspec has changed, i think user should be responsible from calling pod update again.

Also even if current policy will remain the same, we should be more explanatory on command descriptions about what they really do because current descriptions not implies to current behavior. Or my english is not sufficient to get the correct point :)

[neonichu]

@manuyavuz it would be a horrible UX to require the user to run pod update for changes that they don't even know about.

[manuyavuz]

@neonichu my main point was the assumption that the master specs repo does not permit to change a podspec file without a new version. I assume that other repos are mainly private repos that users themselves manage. Therefore I think they mostly know about the changes in their private repos and can perform pod update accordingly.

So, when pod install runs, current system does not re-install a pod if a new version exist, but it does re-install the pod if it's version has not changed but it's content has changed.

I think the main reason of pod install not updating to a newer version is that new version may contain breaking changes for the current project, and user should explicitly give this decision. However, if that pod performs breaking changes in podspec without changing the version, this time pod install will pass those breaking changes.

It fells somewhat non consistent to me, however maybe this is the exact wanted behavior from the install command.

[segiddins]

Yeah, I think we're pretty happy with the current semantics. Having worked on bundler, I know there's no perfect solution, but the one we have now seems to be the most intuitive.

[neonichu]

@manuyavuz I think the difference is that changes to an existing spec are not expected to break any code, but be just really minor changes. So I agree with @segiddins that the current behaviour makes sense.

[manuyavuz]

I got the concerns about the proposal now. Current policy really seems the most appropriate way to handle this for generic usage. Thanks for discussion.

[ovidiuurotaru]

Hi , unfortunately pod install is not working anymore, I always get a timeout error when the spec are updated
fatal: unable to access 'https://github.com/CocoaPods/Specs.git/': Failed to connect to 10.40.212.118 port 8081: Operation timed out, I'm stuck

[benasher44]

Hi @ovidiuurotaru! Thanks for letting us know! If you're still experiencing this, can you please file a new issue and fill out the issue template? If you could do that, we'd be happy to help. Have a great day!