Is there a bundle command to tell me what would be updated with bundle update, without actually making those updates?
As it turns out there is! Bundler 1.1 introduces a new command:
bundle outdated
Show all of the outdated gems in the current bundle.
This will give you a report of gems that have newer versions available.
By itself, this will list all of the gems in your Gemfile.lock that have newer versions, and what the current and latest versions are.
This gives a good preview of what you are up against if you want to get your gems up to date. From there, use git commits to make incremental changes.
Today I created an app with the suspenders gem, and noticed it is running on Rails 3.1.1, which I wanted to upgrade to 3.2.2.
I also saw a few other gems with version attributes:
gem 'sass-rails', '~> 3.1.4'
gem 'coffee-rails', '~> 3.1.1'
gem 'uglifier', '>= 1.0.3'
gem 'rspec-rails', '~> 2.6.1'
gem 'cucumber-rails', '1.1.0'
gem 'capybara-webkit', '~> 0.7.1'
First I ran rake to confirm all tests were passing, bundle update to make sure the gems were all up to date with the versions specified, and created an initial commit.
Next I upgraded to rails 3.2.2 and reran bundle update, and found out (after a couple itterations) that sass-rails and coffee-rails had to be updated too, because of there dependance on ActiveSomethingOrOther. Updating these three gems to their latest versions allowed bundle update to do it’s thing.
I reran my tests, and did ran git diff Gemfile.lock to see exactly what was new. For giggles I reran bundle outdated and rejoiced at the shrinking list. Time to commit with a message about the gem version changes.
From here it was rinse and repeat, checking rubygems.org and looking at the dependencies, making small changes, bundling, raking, committing.
At the end of the road I had a good series of commits spelling out exactly what was needed to get to my goal of a fully updated rails 3.2.2 environment.
If you run bundleoutdated and all you see is:
Outdated gems included in the bundle:
* sprockets (2.4.0 > 2.1.2)
Then you are doing it right!
Read more about what’s new with bundler 1.1 from Pat Shaughnessy.
If you’re not using bundler’s binstubs with RVM integration yet, you should give it a try! This means you don’t have to type “bundle exec” ever again.
Setup:
chmod +x $rvm_path/hooks/after_cd_bundlerbundle install -—binstubsWith rvm integration enabled, the “bin” directory is added to your path each time you cd into a project directory with binstubs. That means you can just run “rake”. If you aren’t ignoring the “bin” directory in your project, you should do so:
# .gitignore
bin/
Since the introduction of bundler to the Ruby community, dealing with dependencies has gotten much easier. Almost every library now has a Gemfile that looks like this:
source "http://rubygems.org"
gemspec
This pulls runtime and development dependencies from your project’s gemspec and finds versions that can all agree with each other. Requiring any of your dependencies will always get the expected version regardless of order, and updating dependencies can be performed with a single command.
However, there’s still one piece missing from this puzzle: how do you make sure that your library works with all supported versions of your dependencies? A common example is Rails: now that Rails 3.1 is out, how can you make sure that your library works with both Rails 3.0.x and Rails 3.1.x?
One side effect of using bundler is that all dependencies are “locked.” This essentially means that, whether you’re running your tests on your home computer, work computer, or continuous integration server, your dependencies are always the same exact versions. This obviously means that you’ll only ever test against one version of Rails; Yehuda Katz, one of the authors of bundler, has a partial answer to this problem:
“When developing a gem, use the gemspec method in your Gemfile to avoid duplication. In general, a gem’s Gemfile should contain the Rubygems source and a single gemspec line. Do not check your Gemfile.lock into version control, since it enforces precision that does not exist in the gem command, which is used to install gems in practice. Even if the precision could be enforced, you wouldn’t want it, since it would prevent people from using your library with versions of its dependencies that are different from the ones you used to develop the gem.”
Unfortunately, there are some holes in this practice.
For one, this means that tests that pass on one machine may not pass on another, even if the library code hasn’t changed at all. This can be frustrating, as it breaks the general expectation that a fresh checkout of any master branch should have passing tests.
For another, this doesn’t reliably exercise your library across versions of your dependencies; rather, it hopes that you happen to run the tests on enough varied environments between each release that you happen to catch any regressions.
If locking your dependencies hides errors, and not locking your dependencies creates them, how can you reliably run your tests on different versions of your dependencies without creating an unstable development environment? The answer is appraisal.
Appraisal runs your tests across configurable, reproducible scenarios that describe variations in dependencies. As an example, if you need to test compatibility with several versions of Rails, you can use an Appraisals file like this:
appraise "3.0" do
gem "rails", "~> 3.0.11"
end
appraise "3.1" do
gem "rails", "~> 3.1.1"
end
You can include as many appraise blocks as you want, and you can be as specific or loose with requirements as you like. Running rake appraisal:install will generate separate bundler-compatible Gemfiles for each scenario, combining the base requirements from your main Gemfile with the changes in each scenario. You can run any rake task across every scenario using the “appraisal” task:
# Run your specs on Rails 3.0 and 3.1
rake appraisal spec
When using Appraisal, we recommend that you check your Gemfile.lock into version control, as well as the gemfiles directory generated by Appraisal. This will ensure that your tests are always green when you check out a fresh copy. It also allows you to create reproducible regression tests for version-specific bugs.
We’ve successfully used Appraisal on numerous projects this year. If you’d like to see real world examples, read the Appraisals files for Clearance, Factory Girl, Capybara Webkit, Copycopter Client, and Paperclip.
Do you have a gem that supports multiple version of Rails or any other library? Find out what your gem is worth: install appraisal.
It’s been two and a half years since my last laptop. It’s neat to look back and see how much has improved since then for setting up a Ruby development environment.
Of particular note, Homebrew, RVM, and Bundler did not exist back then.
Here’s how I set up an OS X 10.7 (Lion) thoughtbot laptop in 2011.
I need GCC to help install everything else so I downloaded GCC for Lion.
We used to have to install XCode to get GCC when OS X wasn’t for developers, which was a 3-4GB download and took 10GB+ of space. Buzzkill.
However, Kenneth Reitz, one of the Readability guys, fixed this with his OS X GCC installer, which is a comparatively svelte 272MB download.
Later on, when we’re installing things using Homebrew, we’ll see warnings like:
Xcode is not installed! Builds may fail!
But, the builds will build fine.
While that’s installing, we’ll customize our environment a little.
I need a public key to get access to private Github repositories.
ssh-keygen -t rsa
I’m kept hitting “enter” until it was done. Alternatively, I could have brought my old SSH key over but I’m not into falconry.
We have a standard set of configurations for vim, irb, git, zsh, and more.
I cloned the repo:
git clone git://github.com/thoughtbot/dotfiles.git
I ran the installer:
./install.sh
This sets up the appropriate symlinks (~/.vimrc, ~/.irbrc, etc.). I’ll stay up-to-date and contribute using the fork-track-update flow described in the README.
Our dotfiles assume zsh so I switched from the bash default to zsh:
chsh -s /bin/zsh
We’re pretty much all vim users here so it’s nice having super-quick home-row access to the Control key… and who uses Caps Lock, anyway?
System Preferences > Keyboard > Modifier Keys
Already installed by default, but I set the global config:
git config --global user.name "Your Name"
git config --global user.email you@example.com
I’m using Heroku for all my apps right now. However, thoughtbot’s clients and even our own apps like Trajectory are not owned by my Heroku account. So, it comes in handy to be able to switch to a different account on a project basis.
heroku plugins:install git://github.com/ddollar/heroku-accounts.git
heroku accounts:add dan --auto
heroku accounts:add thoughtbot --auto
heroku accounts:add client --auto
heroku accounts:default dan
Once GCC is downloaded and installed, I’m ready for the heavy-duty installation using our laptop script.
bash < <(curl -s https://raw.github.com/thoughtbot/laptop/master/mac)
This installs:
It took about 15 minutes for everything to install.
While it’s running, it copies your SSH key to the clipboard and opens your Github SSH page. Paste your SSH key so your Github account is authenticated to your machine.
We wrote a laptop script because we help hundreds of people a year get a Ruby development environment set up at workshops and Boston Ruby hackfests. One time we set up 30 business school students’ laptops in 3 hours.
If you read our source, you’ll see it it’s very simple but more invasive than, say, the excellent Cinderella by Corey Donohoe, which uses Chef to keep your machine tidy. We’re assuming the person definitely wants a “thoughtbot laptop”.
It’s pretty easy to write a wrapper that installs Homebrew, RVM, and your favorite databases and gems so consider forking our project and writing your own script, just like you might write your own Rails template script like Suspenders.
