Nested dependency isn't locked to installed version

[keith]

Currently, if you include a dependency via the :path argument in your Podfile, which has dependencies of its own. The nested dependencies are not locked to the versions they are installed with. Here's an example:

A depends on B and B depends on Alamofire with ~> 3.1.2. When you pod install with A, 3.1.2 is written to the Podfile.lock. Then when Alamofire pushes a new version and you pod install again. The version is bumped in the Podfile.lock even though you did not pod update

Here's an example project showing this issue: http://cl.ly/dtN9 from the fresh state, libPhoneNumber-iOS is in the Podfile.lock as version 0.8.8. When you run pod install it is updated to 0.8.10.

I would expect the Podfile.lock to not be changed unless the user ran pod update.

[segiddins]

This is intentional.

[keith]

Is there reasoning behind it? It seems like the goal of the Podfile.lock is to make sure that you never update something unless you explicitly try to using pod update

[segiddins]

Because you can change anything in a local pod at any time.

[keith]

Shouldn't this still prefer the Podfile.lock's version though? If you changed the podspec intentionally and it didn't match you would get the "can't satisfy both these constraints" error message. Which you would fix with a pod update

[segiddins]

Hm. Maybe. I'd be open to a PR changing that behavior, with test coverage.