Skip to content
This repository

Specifying :head dependency in Podfile does not override other Pod dependency #540

Closed
blakewatters opened this Issue September 21, 2012 · 9 comments

3 participants

Blake Watters Fabio Pelosin Eloy Durán
Blake Watters
Collaborator

Not sure if this is expected behavior or a bug. In our Podfile we have a dependency on RestKit, which currently has a dependency on AFNetworking 1.0. I recently submitted a PR AFN that was merged to master containing a small fix. In trying to pick up this fix, we added pod 'AFNetworking', :head to the Podfile and ran an update. The resulting lock file was still bound to AFNetworking 1.0 and the changes on master did not flow into the Pods directory.

It seems to me that specifying :head in the Podfile should take precedence over the versioned dependency, generate a dependency resolution error, or throw a warning that the versioned dependency is being favored.

Fabio Pelosin

This is a bug. I'll look into it.

Fabio Pelosin

Btw, the intended behavior is that if you change a dependency even (unless it is still compatible, i.e version '1.1' to '> 1.0') pod install should catch it.

Fabio Pelosin

we added pod 'AFNetworking', :head to the Podfile and ran an update

You also kept the old dependency, and didn't comment it?

Blake Watters
Collaborator

Yeah, the RestKit dependency was still in place, which turn had pod 'AFNetworking', '1.0'. What we were expecting to happen was the AF source updating to master and the app + deps building against that. I can recreate the situation if necessary

Fabio Pelosin

I see. So the order does matter. If you call pod 'AFNetworking', :head before pod RestKit you should have the head version. I would be nice if you could confirm that it actually works :-)

I think that we shouldn't generate an error because this allows to modify the dependencies of the specs in the podfile. We check that the versions requirement of the various dependencies are compatible and if not we raise an error, but we don't check for the other dependency options.

We should just document that the order matters. What do you think?

Eloy Durán
Owner

Yes, the resolver is basically a naive implementation like RubyGems has, not like Bundler’s version which implements a much more advanced algorithm. For now I think this is good enough (I would love to re-use Bundler for this in the future), but it should indeed be documented. (I thought I had, bad bad me.)

Fabio Pelosin

Yes, the resolver is basically a naive implementation like RubyGems has, not like Bundler’s version which implements a much more advanced algorithm.

@alloy I'm not familiar with the resolver of Bundler, could you list some of its features that might be desirable for CocoaPods?

Eloy Durán
Owner

Bundler can do full automatic resolves, whereas RubyGems and we will fail if dependencies can’t be satisfied and have the user change fix the failure by, for instance, loading a specific version of a common dependency before anything else, ensuring it will be compatible with other dependencies on that common dependency.

Here’s an explanation of what Bundler does: http://patshaughnessy.net/2011/9/24/how-does-bundler-bundle

Blake Watters blakewatters closed this September 26, 2012
Blake Watters
Collaborator

Ah that makes sense. I had naively assumed that the dependency resolution was more sophisticated -- you really get spoiled from working with Bundler after awhile. Closing and will adjust my deps ordering.

Francis Chong siuying referenced this issue in tombenner/nui January 29, 2014
Merged

Using CoreParse to parse NSS file #198

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.