<RubyGems + Bundler
For many, CocoaPods is the first introduction to dependency management in programming projects. A lot of ideas for CocoaPods came from similar projects ( for example RubyGems, Bundler, npm and Gradle).
Understanding Ruby dependency management is useful because it allows you to specify versions of CocoaPods or other gems and ensure all developers in your team have the exact same version. This guide is for people looking to ensure consistency in their team dependencies or for using un-released versions of CocoaPods.
<RubyGems
RubyGems is a hosted ruby library service. It centralizes where you look for a library, and installing ruby libraries / apps.
You'll have seen gem install xxx. These are installed into a central database of versions. If you imagine that CocoaPods
installs all libraries/frameworks into a System folder and they are linked at runtime, then you have the rough idea
of how RubyGems keeps all the gems.
The downside of this is that there is no way to ensure that a project needing a specific version of a library can use that, it would always use the latest version. So as a developer, you would be cautious installing a new version of a library because it would be used in every library / app. This is the problem bundler solves.
<Bundler
Bundler creates a consistent application environment for your application, by allowing you to specify the version of libraries.
We took this idea almost whole-sale for CocoaPods. You define a Gemfile that says what libraries you want to include, and can
optionally specify a version or range. You run bundle install and it will generate a Gemfile.lock saying the exact version of
all of your libraries and then anyone else running bundle install with that project gets the exact same versions.
<What is a Gemfile?
If you have read the guide on the Podfile, it will feel very similar. A Gemfile is a ruby file that defines your ruby dependencies. Here is an existing one from a Cocoa project.
source 'https://rubygems.org'
gem 'cocoapods'
gem 'cocoapods-keys'
gem 'fui', '~> 0.3.0'
gem 'xcpretty'
gem 'second_curtain', '~> 0.2.3'
gem 'fastlane'
All Gemfiles must include a source for their Gems, other than that you use the more or less the same syntax. This generates a Gemfile.lock which in this case locks CocoaPods to version 0.36.3.
<Using CocoaPods with a Gemfile
With a Gemfile setup, you run bundle install to install, or bundle update to update within your Gemfile's constraints.
From here on in however, you will need to remember to run bundle exec before any terminal commands that have come in via
bundler. Given that CocoaPods is included in the above this means any time you would write pod XX YY you need to do bundle exec pod XX YY.
Doing it without bundle exec will bypass your Gemfile's specific versioning and will use the latest version of the library within RubyGems. This
could potentially be the exact same version, but it can often not. If you are including CocoaPods plugins then they may also not be ran.
This means you can be sure that foundational tooling for projects are versioned just like your personal libraries.
<Using master CocoaPods
Often in-between releases you may be interested in using a Gemfile to work with an unreleased version of CocoaPods. Due to the size of the project we try to release slowly when we're sure it won't break projects. Like with CocoaPods you can easily use master, or forks of your ruby project. Here is an example of a Gemfile using CocoaPods master.
source 'https://rubygems.org'
gem 'cocoapods', :git => 'https://github.com/CocoaPods/CocoaPods.git'
gem 'cocoapods-core', :git => 'https://github.com/CocoaPods/Core.git'
gem 'xcodeproj', :git => 'https://github.com/CocoaPods/Xcodeproj.git'
gem 'cocoapods-keys', :git => 'https://github.com/orta/cocoapods-keys.git'
gem 'xcpretty'
gem 'shenzhen'
gem 'sbconstants'
Running bundle install will get the versions from master. As CocoaPods is multiple gems, you may have to include other dependencies like above.