Specify a specific commit hash as a dependency in Podfile

[jk]

From time to time I want to use a more recent version of a dependency which is not yet tagged as a stable version. For example when there is a bug in the tagged stable version for which the bugfix commit is already in the repo but not tagged. I want something like the following in my Podfile:

dependency 'XYProject', '~> commit:af3dd2ac231d'

Your mileage may vary on the syntax, but I think the idea behind this is clear. What do you think, is this something considered useful or does undermine the idea behind CocoaPods?

[fabiopelosin]

If I recall correctly, you can already to it if the repo contains a podspec in the root. Alternatively you can define an inline podspec.

There is also a ticket open for something similar: #116. Although, the idea of specifying a commit hasn't been discussed.

What do you think, is this something considered useful or does undermine the idea behind CocoaPods?

Given the previous comment of @alloy, and in my opinion, this is a welcome feature. Is it something that you wan't to work on?

[jk]

Given the previous comment of @alloy, and in my opinion, this is a welcome feature. Is it something that you wan't to work on?

I'm not sure if I have the skills to do that, since I lack the ruby background. But on the other side why not? It can't be to hard, since checking tags out isn't that different from checking out a specific commit, is it?

[fabiopelosin]

I'm not sure if I have the skills to do that, since I lack the ruby background. But on the other side why not?

It is up to you, I asked in case you were interested. Anyway, if you decide to go on I can help you.

It can't be to hard, since checking tags out isn't that different from checking out a specific commit, is it?

We already have a downloader sophisticated enough to handle commits (the only thing missing is branches support but there is a pull for that). It is mostly a matter of overriding the download options of the podspec with the ones specified in the podfile.

Nonetheless, before starting on this feature it would be better to complete the discussion on CocoaPods/Specs#184 as it could make the point of this issue moot.

[fabiopelosin]

I'm closing this because I think that the current syntax is good enough for common cases. Now, that we will introduce better support for custom repos in those cases where more control is needed it is always possible to create a podspec.

Finally this proposal would make the podfile syntax, and the dependency resolution more complicated which is never good.

Feel free to reopen if you disagree.

[kristi]

Would you consider reopening this?

It's frustrating trying to update a pod when the author hasn't tagged a new version. Using :head is sort of nice to get the most recent version, but it doesn't guarantee that everyone on our dev team will be using the same source version if the pod source code is being updated. Manually copying the podspec to our source code repo just to specify the commit is a lot of work. Having a :commit shortcut which worked like :head to use in the Podfile would be most convenient.

Also, although you can specify

pod PodName, :git => 'https://github.com/name/proj', :commit => '1234abcd'

this doesn't work if the library doesn't have a podspec in its root. Ironically, if the library had a podspec, I would expect the podspec to be up to date and the repo properly tagged, which means I probably wouldn't be looking to have to manually specify a commit.

[rsobik]

I agree with @kristi's comment. In my eyes, it is difficult to have two podspec files in two different locations. I think that the podspec in the specs repo should be the master podspec and the only one needed. This is the reason I implemented pod spec cat NAME in the 0.17 branch.

I understand that there are situation where you want to point to a spec file inside the project directory, especially when you are refactoring the project. I think this should be optional and not mandatory.

@kristi I think that using :head is fine because CocoaPods creates the Podfile.lock file during a pod update or the first pod install. Subsequent pod install calls use the lockfile to obtain the commits and repos. So everyone on your team using pod install should be fine.

[fabiopelosin]

Using :head is sort of nice to get the most recent version, but it doesn't guarantee that everyone on our dev team will be using the same source version if the pod source code is being updated.

As @rsobik points the intended solution is to store that information in the Podfile.lockfile. However that feature is not implemented for head downloads yet.

We decided to go for this route because the pod command of the Podfile already has too many options and we are concerned to keep the DSL simple. Also allowing such syntax could create issues along the road as it doesn't work well with the dependency resolution process. Finally tagging with semantic versions is very cheap so we think that all the libraries should be tagged as it provides important information not captured by the SHA (even for clients which don't use CocoaPods).

In case the author refuses to tag it is possible to create a repo for your team. So there is no need to copy the podspec inside the repository of your project.

I understand that there are situation where you want to point to a spec file inside the project directory, especially when you are refactoring the project. I think this should be optional and not mandatory.

We do it this way because there is not a reliable way to resolve which podspec to use with an SHA. We could use the latest know, but it would not work in many cases and create more frustration.

---

However this is not a completely resolved, lets fix the foundation first and see how the Objective-C community evolves.

[kristi]

Thanks for the update, makes sense.

Is there a ticket or a rough timeline for the Head tagging in the lockfile? I'm interested in knowing when that's implemented.

[fabiopelosin]

CocoaPods just wen through a major refactoring and this feature could make it for the 0.17. In any case a big part of the important logic is already implemented so it should come relative soon.