4 ms·

Rubies and Bundles - switching from RVM to rbenv

48 points by hcm 14y ago

zimbatm 14y ago
Just a little plug, I wrote this language-agnostic environment loader: http://direnv.net http://direnv.net . Unline rvm it doesn't hijack all your shell builtins and is very lightweigh (keeps your prompt fast). I use it every day load load ruby/python/go/... projects in isolation.
llasram 14y ago
For something even simpler, check out redenv -- https://github.com/damballa/redenv https://github.com/damballa/redenv . It tries to provide something which works more like Python's virtualenv, just doing the minimum necessary to setup an environment referencing a particular system-provided Ruby installation, but with an isolated gemset.
masnick 14y ago
I've never found it necessary to use the --path or --binatubs options with rbenv. For --path, I just use the default which presumably puts everything in the main rbenv folder for gems. I've never had a problem with this. For the problem of having to type "bundle exec" before every command that uses a binary from a gem, I've heard of two alternative solutions. One is aliasing "bundle exec" to "be" or something to make it quicker to type. The other is using zsh/oh-my-zsh instead of bash and using a plugin (can't remember the name off the top of my head) that automatically figures out what should be bundle execed and takes care of it behind the scenes. I've never had trouble with this either.
- hcm 14y ago
  The issue with not using --path is that gems will leak between different projects, so you'll probably run in to trouble when projects depend on different versions of the same gem. I've also used shell plugins to remedy the bundle exec issue, but they've often caused more problems than they solve. I'd much rather just stick something in my PATH than use shell plugins.
  - yxhuvud 14y ago
    Isn't this solved by storing Gemfile.lock? I thought that was the whole purpose of that file..
  - elektronaut 14y ago
    I find it much easier to simply explicitly require a specific version in my Gemfile if I'm having trouble with a gem, rather than having the extra overhead of managing multiple sets of gems. I think it's a more correct solution as well. You won't have any guarantees that Bundler will resolve the dependencies correctly in production when it doesn't in your development environment.
    - hcm 14y ago
      That's also a good approach. The moving the bundler binstubs to a central location would work nicely as well, I imagine.
      - elektronaut 14y ago
        Absolutely. I'm using oh-my-zsh with the bundler plugin, which aliases all binstubs to a function that prepends bundle exec if there's a Gemfile. It works very well in practice. rbenv handles the correct ruby version, Bundler loads the right gem, and it all falls back to the newest version on the system default ruby. It's a few more moving parts behind the scenes than I'd prefer, but once configured it's completely transparent.
hayksaakian 14y ago
In one of the linked posts they compare it to the rails vs Sinatra relationship, but in this case, since rvm and rbenv don't ever make their way to a consumer there's no real reason to switch. I suppose if you're someone who has to work with multiple Ruby versions, it COULD save you time switching between them.
darrencauthon 14y ago
Sometimes the simpler solution is the more complex tool -- if that's what everybody already uses and if it already works. Just like RVM.
- mattdeboard 14y ago
  If the python community felt this way we'd all still be using easy_install and installing our libraries at system root.
  - crusso 14y ago
    You're talking about huge degrees of difference between easy_install and what came after vs rvm vs rbenv. Personally, I never have trouble with rvm. It works great despite a little magic and I like the way that I can use it without having to worry about installing bundler, installing binary shims, etc. Speaking of attitudes affecting the Python community, does it have anything approaching the ease of use of rbenv or rvm yet?
  - darrencauthon 14y ago
    I'm not saying it's always the rule. It depends on the context. If the context is a group of Ruby/Rails devs who are efficiently building applications in exchange for money, and the new(er) tool is one that: 1.) Ends with the same net result for the developer, and 2.) Adds a little bit of complexity on setup and rules around use, then why switch? I'm perfectly willing to trade up my development tools, but I want a better net gain before I switch. Perhaps that net gain will be to keep up with a growing number of devs who use it? We'll see.
    - dlisboa 14y ago
      You can use the right tools in the wrong way and be productive. You're still using them wrong. Most people use Bundler and RVM gemsets in a way that Bundler wouldn't even be needed. Rbenv forces you to learn the proper way of project management and it actually reduces complexity once people get over the small learning curve of using the correct tools for each thing. Bundler manages dependency, Rbenv just switches rubies. RVM adds so much more that it blurs the lines between things.
bradleyland 14y ago
Why manage something manually when there are good tools to abstract it away in to the background? That's kind of the feeling I get when using rbenv + bundler. Let me predicate this by pointing out that I manage a lot of Ruby projects (many are old) that require a wide variety of Ruby and gem versions. Obviously my solution isn't the best for everyone. Some developers will never have to worry about conflicting gem versions, because they work primarily on one project with one set of dependencies. The incremental value of the items I'm about to point out don't represent significant value to them. Enough with the disclaimers. Bundler has the ability to alter your Ruby env variables so that you can easily install and execute gems from any location. This is the feature that allows you to use completely different gems across many projects without any conflicts. As the author suggests, you can pass a path at the time you invoke `bundle install` as a means to specify this location. This allows you to segregate gems to avoid conflicts. The author also points out that the trade-off is "one annoying side effect: any binaries that are installed (e.g. rspec, foreman, cap) are no longer available in your shell’s path". Bummer. I wonder if there's a way around that? Hey, we could manage our environment so that these items are in our path, but remain segregated. We could even write some tidy scripts that automate it for us. Enter RVM. This is why I don't understand the drive to move to rbenv for developers who need these features. I use RVM and bundler all the time. RVM doesn't preclude the use of bundler, and bundler doesn't make RVM obsolete. When I establish an RVM gemset and .rvmrc, I've abstracted away all the '--path=./.somebundledir' and `bundle exec` nonsense. I only think about it once, then I'm free to use the tools without additional cruft. I'm probably happier than I should be that I can type `cap staging deploy:pending` instead of `bundle exec cap staging deploy:pending`. If you don't need gemsets, or you're only managing a very small number of Ruby projects, I suppose I can understand wanting a simpler tool, but I don't find RVM terribly complex. A lot of people will say "choice is good", but principle applied without cause isn't good, it's just pedantic.
- hcm 14y ago
  Perhaps it wasn't clear enough, but the post pointed out that typing 'bundle exec' and explicitly using --path isn't necessary. Once you've added one item to your PATH, and two lines to your bundler config file, you don't need to think about it ever again, it just works. If you want all your gems in one place, simply remove the BUNDLE_PATH line and change the BUNDLE_BIN directory to whatever you want (presumably something within your home directory). I don't want to get in to the rbenv vs RVM debate - they're both good tools and it's an issue that has been done to death. I linked to five articles in the post, and you can find many, many more with a simple Google. My personal motivation for switching was that bundler's overridden 'cd' function includes some commands that fail, which is fine under most circumstances but it breaks as soon as you use 'set -e' in bash. We spoke to the author and he said he said that RVM wouldn't be 'set -e' compatible in the foreseeable future.
patrickslee 14y ago
But there is https://github.com/carsomyr/rbenv-bundler https://github.com/carsomyr/rbenv-bundler already.

48 points by hcm 14y ago

Just a little plug, I wrote this language-agnostic environment loader: http://direnv.net http://direnv.net . Unline rvm it doesn't hijack all your shell builtins and is very lightweigh (keeps your prompt fast). I use it every day load load ruby/python/go/... projects in isolation.

llasram 14y ago

For something even simpler, check out redenv -- https://github.com/damballa/redenv https://github.com/damballa/redenv . It tries to provide something which works more like Python's virtualenv, just doing the minimum necessary to setup an environment referencing a particular system-provided Ruby installation, but with an isolated gemset.

masnick 14y ago

I've never found it necessary to use the --path or --binatubs options with rbenv. For --path, I just use the default which presumably puts everything in the main rbenv folder for gems. I've never had a problem with this. For the problem of having to type "bundle exec" before every command that uses a binary from a gem, I've heard of two alternative solutions. One is aliasing "bundle exec" to "be" or something to make it quicker to type. The other is using zsh/oh-my-zsh instead of bash and using a plugin (can't remember the name off the top of my head) that automatically figures out what should be bundle execed and takes care of it behind the scenes. I've never had trouble with this either.

hcm 14y ago
The issue with not using --path is that gems will leak between different projects, so you'll probably run in to trouble when projects depend on different versions of the same gem. I've also used shell plugins to remedy the bundle exec issue, but they've often caused more problems than they solve. I'd much rather just stick something in my PATH than use shell plugins.
- yxhuvud 14y ago
  Isn't this solved by storing Gemfile.lock? I thought that was the whole purpose of that file..
- elektronaut 14y ago
  I find it much easier to simply explicitly require a specific version in my Gemfile if I'm having trouble with a gem, rather than having the extra overhead of managing multiple sets of gems. I think it's a more correct solution as well. You won't have any guarantees that Bundler will resolve the dependencies correctly in production when it doesn't in your development environment.
  - hcm 14y ago
    That's also a good approach. The moving the bundler binstubs to a central location would work nicely as well, I imagine.
    - elektronaut 14y ago
      Absolutely. I'm using oh-my-zsh with the bundler plugin, which aliases all binstubs to a function that prepends bundle exec if there's a Gemfile. It works very well in practice. rbenv handles the correct ruby version, Bundler loads the right gem, and it all falls back to the newest version on the system default ruby. It's a few more moving parts behind the scenes than I'd prefer, but once configured it's completely transparent.

hayksaakian 14y ago

In one of the linked posts they compare it to the rails vs Sinatra relationship, but in this case, since rvm and rbenv don't ever make their way to a consumer there's no real reason to switch. I suppose if you're someone who has to work with multiple Ruby versions, it COULD save you time switching between them.

darrencauthon 14y ago

Sometimes the simpler solution is the more complex tool -- if that's what everybody already uses and if it already works. Just like RVM.

mattdeboard 14y ago
If the python community felt this way we'd all still be using easy_install and installing our libraries at system root.
- crusso 14y ago
  You're talking about huge degrees of difference between easy_install and what came after vs rvm vs rbenv. Personally, I never have trouble with rvm. It works great despite a little magic and I like the way that I can use it without having to worry about installing bundler, installing binary shims, etc. Speaking of attitudes affecting the Python community, does it have anything approaching the ease of use of rbenv or rvm yet?
- darrencauthon 14y ago
  I'm not saying it's always the rule. It depends on the context. If the context is a group of Ruby/Rails devs who are efficiently building applications in exchange for money, and the new(er) tool is one that: 1.) Ends with the same net result for the developer, and 2.) Adds a little bit of complexity on setup and rules around use, then why switch? I'm perfectly willing to trade up my development tools, but I want a better net gain before I switch. Perhaps that net gain will be to keep up with a growing number of devs who use it? We'll see.
  - dlisboa 14y ago
    You can use the right tools in the wrong way and be productive. You're still using them wrong. Most people use Bundler and RVM gemsets in a way that Bundler wouldn't even be needed. Rbenv forces you to learn the proper way of project management and it actually reduces complexity once people get over the small learning curve of using the correct tools for each thing. Bundler manages dependency, Rbenv just switches rubies. RVM adds so much more that it blurs the lines between things.

bradleyland 14y ago

Why manage something manually when there are good tools to abstract it away in to the background? That's kind of the feeling I get when using rbenv + bundler. Let me predicate this by pointing out that I manage a lot of Ruby projects (many are old) that require a wide variety of Ruby and gem versions. Obviously my solution isn't the best for everyone. Some developers will never have to worry about conflicting gem versions, because they work primarily on one project with one set of dependencies. The incremental value of the items I'm about to point out don't represent significant value to them. Enough with the disclaimers. Bundler has the ability to alter your Ruby env variables so that you can easily install and execute gems from any location. This is the feature that allows you to use completely different gems across many projects without any conflicts. As the author suggests, you can pass a path at the time you invoke `bundle install` as a means to specify this location. This allows you to segregate gems to avoid conflicts. The author also points out that the trade-off is "one annoying side effect: any binaries that are installed (e.g. rspec, foreman, cap) are no longer available in your shell’s path". Bummer. I wonder if there's a way around that? Hey, we could manage our environment so that these items are in our path, but remain segregated. We could even write some tidy scripts that automate it for us. Enter RVM. This is why I don't understand the drive to move to rbenv for developers who need these features. I use RVM and bundler all the time. RVM doesn't preclude the use of bundler, and bundler doesn't make RVM obsolete. When I establish an RVM gemset and .rvmrc, I've abstracted away all the '--path=./.somebundledir' and `bundle exec` nonsense. I only think about it once, then I'm free to use the tools without additional cruft. I'm probably happier than I should be that I can type `cap staging deploy:pending` instead of `bundle exec cap staging deploy:pending`. If you don't need gemsets, or you're only managing a very small number of Ruby projects, I suppose I can understand wanting a simpler tool, but I don't find RVM terribly complex. A lot of people will say "choice is good", but principle applied without cause isn't good, it's just pedantic.

hcm 14y ago
Perhaps it wasn't clear enough, but the post pointed out that typing 'bundle exec' and explicitly using --path isn't necessary. Once you've added one item to your PATH, and two lines to your bundler config file, you don't need to think about it ever again, it just works. If you want all your gems in one place, simply remove the BUNDLE_PATH line and change the BUNDLE_BIN directory to whatever you want (presumably something within your home directory). I don't want to get in to the rbenv vs RVM debate - they're both good tools and it's an issue that has been done to death. I linked to five articles in the post, and you can find many, many more with a simple Google. My personal motivation for switching was that bundler's overridden 'cd' function includes some commands that fail, which is fine under most circumstances but it breaks as soon as you use 'set -e' in bash. We spoke to the author and he said he said that RVM wouldn't be 'set -e' compatible in the foreseeable future.

patrickslee 14y ago

But there is https://github.com/carsomyr/rbenv-bundler https://github.com/carsomyr/rbenv-bundler already.