Don't ever run bundle update(optimisdev.com)
optimisdev.com
Don't ever run bundle update
http://optimisdev.com/posts/don-t-ever-run-bundle-update
4 comments
Agree with everything you're saying here. What happened in our situation was someone had been working on a feature branch for a few weeks, merged in to the mainline development branch (with failing tests exposing this issue, grr!), and then began the git bisect dance to find the commit that caused the failure.
One point I was trying to make in the post (maybe made poorly), was that you probably never want to update the entire gem dependency graph in one fell swoop, just for the hell of it.
My read on this is that people tend to do this because they don't fully understand what bundle update is doing when run without any arguments. In the pre-1.0 days, the difference between those commands, at least in my eyes, was extremely ambiguous.
So IMHO, updating all gem dependencies to their latest versions, if only for the purpose of "staying current", usually doesn't make practical sense. Sure, there will be bugfixes included in these updates, but unless they were critical security patches, you can probably live without them, unless those bugs are affecting you directly. Even in that case, I would say the solution would be to run bundle update gem-name, only for that gem.
One point I was trying to make in the post (maybe made poorly), was that you probably never want to update the entire gem dependency graph in one fell swoop, just for the hell of it.
My read on this is that people tend to do this because they don't fully understand what bundle update is doing when run without any arguments. In the pre-1.0 days, the difference between those commands, at least in my eyes, was extremely ambiguous.
So IMHO, updating all gem dependencies to their latest versions, if only for the purpose of "staying current", usually doesn't make practical sense. Sure, there will be bugfixes included in these updates, but unless they were critical security patches, you can probably live without them, unless those bugs are affecting you directly. Even in that case, I would say the solution would be to run bundle update gem-name, only for that gem.
I tend to run `bundle update` all the time for the hell of it during development, when the code is not deployed/being used live anywhere. The codebase is by definition full of bugs anyway because I haven't finished it. May as well be full of the latest bugs, having other people's already fixed bugs in there seems a shame.
When I am working on code that is already being used by others and the changes are aimed to be pushed out pretty much as soon as they're 'ready,' I am much more careful and selective about dependency updates.
When I am working on code that is already being used by others and the changes are aimed to be pushed out pretty much as soon as they're 'ready,' I am much more careful and selective about dependency updates.
+1
I've found myself in the situation, a few times, where it was necessary to run `bundle update' to resolve dependency conflicts. You should, of course, always thoroughly test your application before deploying production code after a `bundle update', but I'd hardly tell people to not "ever" run the command, especially if you have git-based dependencies that need to be updated.
Just to clarify, you can always run bundle update for a specific gem, instead of for every gem in the Gemfile (this is the behavior if you run the command without any arguments). Recent versions of bundler (>=1.0) are pretty good about telling you exactly which gems have dependency conflicts, so it should be pretty easy to determine which gem to pass to bundle update.
Just have the Gemfile.lock changes in a separate commit. Regreted it many times I didn't.
Does anyone know if there's a command to update your Gemfile to the latest available version of all gems used?
I'd prefer this b/c it's usually easy to roll back one or two before deploying if they conflict on my laptop, and having a defined version is preferable to blindly going with the latest.
I'd prefer this b/c it's usually easy to roll back one or two before deploying if they conflict on my laptop, and having a defined version is preferable to blindly going with the latest.
That's what bundle update does, with no other arguments. The other way to use it is bundle update gem-name, which will only update the gem passed in and it's dependencies.
It doesn't update the version numbers in the Gemfile, though, does it? IOW it's only for gems that you haven't locked in a specific version for?
I'd love to be able to ask bundler which of the gems that I have locked in a version for have a newer version available, so that I can test and decide if I should update.
I'd love to be able to ask bundler which of the gems that I have locked in a version for have a newer version available, so that I can test and decide if I should update.
No, it won't update the version numbers in your Gemfile. But to be clear, let's assume you have the following in your Gemfile:
So, rails has a "specific" dependency on actionpack = 3.0.0, and actionpack 3.0.0 has a dependency on erubis ~> 2.6.6. Let's say (hypothetically) the most recent published version of erubis is 2.6.7 (which matches the ~> operator), but the version in your Gemfile.lock is 2.6.6, running bundle update will pull down that new version of erubis 2.6.7.
Similarly, if a newer version of formtastic were available than the one in your Gemfile.lock, bundle update would pull this down as well.
gem "rails", "3.0.0"
gem "formtastic", ">=1.0.0"
So, rails has a "specific" dependency on actionpack = 3.0.0, and actionpack 3.0.0 has a dependency on erubis ~> 2.6.6. Let's say (hypothetically) the most recent published version of erubis is 2.6.7 (which matches the ~> operator), but the version in your Gemfile.lock is 2.6.6, running bundle update will pull down that new version of erubis 2.6.7.
Similarly, if a newer version of formtastic were available than the one in your Gemfile.lock, bundle update would pull this down as well.
In general I have varying levels of confidence in whether I want to stay at the latest version of a gem or not.
I also don't want to have to constantly check to see if the gems for which I've fixed the version are the latest... During development I'd be inclined to keep most gems at the latest version (barring the sort of conflict you describe), but once the app is in production I'd be likely to be more cautious, read the changelog, etc., before updating.
It's just that when there are a lot of gems in use, it becomes time consuming to have to cross-reference the lastest version of each gem whose version I have fixed with the latest released version. It seems that Bundler is the natural place for this functionality to live.
I also don't want to have to constantly check to see if the gems for which I've fixed the version are the latest... During development I'd be inclined to keep most gems at the latest version (barring the sort of conflict you describe), but once the app is in production I'd be likely to be more cautious, read the changelog, etc., before updating.
It's just that when there are a lot of gems in use, it becomes time consuming to have to cross-reference the lastest version of each gem whose version I have fixed with the latest released version. It seems that Bundler is the natural place for this functionality to live.
The ~> operator is the only one you should really use in your Gemfile version strings. Never >=
See this post by yehuda katz (bundle developer): http://yehudakatz.com/2010/08/21/using-considered-harmful-or...
You can actually use `bundle update` pretty safely with judicious use of ~>
See this post by yehuda katz (bundle developer): http://yehudakatz.com/2010/08/21/using-considered-harmful-or...
You can actually use `bundle update` pretty safely with judicious use of ~>
Yes, a `bundle update --pretend` switch or similar would be good.
It's not really "blindly"; if you run `bundle update', the latest versions are documented in the Gemfile.lock.
You'll need `bundle update foo` if foo has a git source, e.g. `gem 'foo', :git => 'git://github.com/johndoe/foo.git'`, and new code committed that you want.
It's not as simple as saying never use it.
It's not as simple as saying never use it.
Sorry. Maybe I should've been more clear in the post to say that you should almost never use bundle update without arguments, which updates the entire gem dependency graph. Running that command with an argument will only resolve dependencies (and perform updates) for the gem passed in as an argument to update command. Apologies for any confusion there :-)
Just make sure you do your `bundle update` and then immediately run your test suite and then immediately commit to your repo, before touching any actual code. Mods to Gemfile.lock should always exist in a commit on their own so that you can easily trace any bugs back to dependency upgrades.
If you don't have source control or a test suite, you are fucked. But then you're probably fucked anyway.