Today I learned that besides of using CocoaPods pod specs via the official repo, you can also use local clones of the source code as pods.
Up until now I was maintaining that one drawback of CocoaPods would be that it keeps a copy of all source files in the Pods subfolder of your project. If you made a change it would be hard to get the updates back into the upstream.
Holger Singbaek taught me that you can also reference a local clone of a git repository holding a component. Consider the following Podfile:
platform :ios, '5.0' pod 'DTCoreText', :path => '~/Documents/Projects/DTCoreText/', :branch => 'develop'
Note: you need CocoaPods version 0.19 for that to work. Do a gem update cocoapods if you don’t have the current released version.
If you have a project file in the same folder as the Podfile, this will set up a workspace to look like this:
You can see that instead of the Pods group there is a new Local Pods group holding the local pod. Since DTCoreText references several DTFoundation sub-specs this is still present here in the traditional place. All file references in the Pods project reference the original files in the specified local clone.
The M (for modified) you see here is from default.css being compiled during the pod installation into a c file so that it can be linked into the static library.
With this setup you can go about developing your app and even use the latest (and hopefully greatest) version of the component. If you make any changes to the files you are editing the files in the local repository. Xcode should even be able to submit these commits to the correct repository from within the UI.
Conclusion
Local Pods allow you to integrate via pod local clones of components. Changes you make to the local files can then be submitted to the repo upstream with ease.
Thank you Holger for pushing my knowledge forward in this matter. Thanks also go to to Fabio Pelosin who – being a contributor to the CocoaPods project – helped us find a workaround for a bug that exists in the post_install hook and showed us pre_install as an alternative.
With this enhancement DTCoreText 1.5 is now working both as a remote as well as a local pod.
Categories: Recipes
Nice post! But how do you update DTCoreText to e.g. 1.6 then? That will override your local changes again, right?
Local changes should only ever be temporary when using other people’s components.
This seems like a fairly temperamental approach though, since you’d have to guarantee that all others that pull your git repo have DTCoreText cloned at ~/Documents/Projects/DTCoreText/. Any suggestions to avoid that? The best we can think of is to make the path relative and put DTCoreText in the git repo, but that at least partially defeats the purpose of the local pod… keeping a copy of DTCoreText source code in the repo.
As a followup to my previous comment, see http://albertodebortoli.github.io/blog/2014/03/11/cocoapods-working-with-internal-pods/.
Wonderful blog! I found it while searching on Yahoo News. Do you have any tips on how to get listed in Yahoo News? I’ve been trying for a while but I never seem to get there! Appreciate it