0

I have some doubt on CocoaPods

  1. I think the 1st rule is that keep Podfile and ignore pods folder entirely. But I am so confused about this after I have used some time
  2. Since I insist on #1, somebody says *.lock should be kept in repo. Do I need do this?
  3. Pods generates some xconfig files, it seem I can't add HEADER_SEARCH_PATH in it ? if YES, it breaks my rule #1 again. Please see this question the-target-overrides-the-other-ldflags-build-setting-defined-in-pods-pods
  4. some buddies modify codes managed by CocoaPods such as AFNetworking rather than from custom repo. I told him NEVER do this because it will recover to origin version after pod update/install but after pod update/install his code didn't change. that's WHY?

My opinion is DON'T MODIFY EVERTHING IN PODS PROJECT EXCEPT PODFILE

Community
  • 1
  • 1
aelam
  • 2,796
  • 2
  • 27
  • 32
  • if you want to find useful idea for handling external repos in your project, I would recommend you to take a look on _GIT repos_ and its _submodules_ or _subtrees_. much less headache. – holex Oct 29 '14 at 15:25
  • 1
    I agree with holex. The correct way to use CocoaPods is to not use CocoaPods. – quark Oct 29 '14 at 16:01

1 Answers1

3

You should always check in your Podfile and Podfile.lock.

Checking in your Pods directory is debatable. If you would like to be able to clone the project and run it without requiring users to have CocoaPods you should check this in. I personally do not check this directory in, instead you just have to run pod install after cloning the project for the first time.

If you want to alter the xcconfig files with changes such as HEADER_SEARCH_PATH you should check this in so those settings don't get overwritten unintentionally. Really the podspec should handle all of these settings so you probably shouldn't be changing much in there.

If you're planning on altering the code included by a Pod you should either check in your Pods folder or fork the repo and redirect it to in your Podfile. Documentation on that here. This way you can specify that CocoaPods uses the given spec but uses your fork instead.

EDIT The Podfile.lock (similar to the Gemfile.lock) stores information on the actual version included during the install. Consider this:

  1. You require a spec like pod 'foo', '~> 1.0.0 in your Podfile.
  2. You run pod install and it installs the newest version of foo matching the semantic versioning conventions (specified by ~>)
  3. You don't check in your Podfile.lock
  4. Another developer clones the repo, the newest version of foo is now 1.0.3.
  5. They run pod install. Version 1.0.3 is installed even though they didn't run pod update.

This information is 'locked' in the Podfile.lock so that to do this you have to run pod update which should be very intentional.

Keith Smiley
  • 61,481
  • 12
  • 97
  • 110
  • One must consider all the risks of CocoaPods as well: 1. When updating to a new version of CocoaPods, the user has no idea if a bug will be introduced that will break their build process. As such, the user's build process may stop working which could impact release dates. 2. Inevitably, one will come across a third-party library that doesn't use CocoaPods, and as such the user will have a mix of Pods and non-Pods in their project anyway. With the character limit about reached, bottom line is, git submodules do the work of CocoaPods without the headache of dealing with bugs *in* CocoaPods – quark Oct 29 '14 at 17:36
  • I don't know why do I need check in Podfile.lock while podfile can keep all developers consistent. – aelam Oct 29 '14 at 17:46
  • http://stackoverflow.com/questions/18376416/the-target-overrides-the-other-ldflags-build-setting-defined-in-pods-pods I can fix this kind by adding ${inherit} , then I don't need checkin xconfig by this way. I think CocoaPods is designed only have one config file(Podfile) How do you think? – aelam Oct 29 '14 at 17:53
  • @aelam I've added info about the `Podfile.lock` – Keith Smiley Oct 29 '14 at 18:34
  • @quark I'm not arguing for or against CocoaPods as that was not the original question. This is how you do what the original author wanted using CocoaPods. If you would like to advocate for another solution you should post that as an answer. – Keith Smiley Oct 29 '14 at 18:35
  • 1
    @quark I don't think (1) is a consequence of cocoapods. It's true whenever you rely on any third party software. Xcode has been known to break my build process after a new release. For (2) you can always fork the repository and add your own cocoapods manifest. Git submodules come with a completely different set of headaches. I personally am fine with using either one, but both require some amount of effort and knowledge of what you're doing. Personally I do not commit the Pods/ folder, but my coworkers all seem to want to do it. So I live with it. – i_am_jorf Oct 29 '14 at 18:41
  • @KeithSmiley If the Podfile.lock works as you said, I prefer to specify version number like `pod 'foo', '~> 1.0.0` , `pod update` and `pod install` will both be fine, no matter Podfile.lock it is. Mostly developers won't change the version number on risk. even the version number is changed by somebody, It's easier to find it back – aelam Oct 30 '14 at 10:28
  • @aelam here's the [relevant documentation](http://guides.cocoapods.org/using/using-cocoapods.html#what-is-a-podfilelock). Also note "This file should always be kept under version control." – Keith Smiley Oct 30 '14 at 16:39