4 ms·

Don't ever run bundle update

18 points by ajsharp 16y ago

stephencelis 16y ago
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.
- effkay 16y ago
  Just have the Gemfile.lock changes in a separate commit. Regreted it many times I didn't.
- ajsharp 16y ago
  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.
JonnieCache 16y ago
If you have a problem where you have auto-updated your whole bundle with `bundle update` and your app is now broken, just remember that you can run `git checkout Gemfile.lock` to revert back to your previous situation. Not really as big a problem as the article makes out. 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.
- ajsharp 16y ago
  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.
  - JonnieCache 16y ago
    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.
    - ajsharp 16y ago
      +1
sjtgraham 16y ago
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.
- ajsharp 16y ago
  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 :-)
grandalf 16y ago
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.
- stephencelis 16y ago
  It's not really "blindly"; if you run `bundle update', the latest versions are documented in the Gemfile.lock.
- ajsharp 16y ago
  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.
  - grandalf 16y ago
    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.
    - JonnieCache 16y ago
      Yes, a `bundle update --pretend` switch or similar would be good.
    - ajsharp 16y ago
      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: gem "rails", "3.0.0" gem "formtastic", ">=1.0.0" Running bundle update (with no arguments) won't update the rails gem to a more recent version (if it exists), but it will update any of rails' dependencies, if updates exist. 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.

18 points by ajsharp 16y ago

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.

effkay 16y ago
Just have the Gemfile.lock changes in a separate commit. Regreted it many times I didn't.
ajsharp 16y ago
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.

JonnieCache 16y ago

If you have a problem where you have auto-updated your whole bundle with `bundle update` and your app is now broken, just remember that you can run `git checkout Gemfile.lock` to revert back to your previous situation. Not really as big a problem as the article makes out. 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.

ajsharp 16y ago
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.
- JonnieCache 16y ago
  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.
  - ajsharp 16y ago
    +1

sjtgraham 16y ago

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.

ajsharp 16y ago
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 :-)

grandalf 16y ago

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.

stephencelis 16y ago
It's not really "blindly"; if you run `bundle update', the latest versions are documented in the Gemfile.lock.
ajsharp 16y ago
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.
- grandalf 16y ago
  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.
  - JonnieCache 16y ago
    Yes, a `bundle update --pretend` switch or similar would be good.
  - ajsharp 16y ago
    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: gem "rails", "3.0.0" gem "formtastic", ">=1.0.0" Running bundle update (with no arguments) won't update the rails gem to a more recent version (if it exists), but it will update any of rails' dependencies, if updates exist. 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.