6

I've just switched from years of development with RVM to rbenv and there is one aspect of rbenv that I can't seem to wrap my head around:

When I am working on multiple projects (each with their own dependencies) under the same version of Ruby and then stop working on one of the project how can I easily upgrade all of its dependencies from my gempath (which is apparently /Users/meltemi/.rbenv/versions/2.1.4/lib/ruby/gems/2.1.0)?

With RVM every project had a gemset so it was easy to delete it.

With rbenv it would appear that every version of every gem goes into the same directory where bundler can manage it. Great! But say I go through a bundle outdated and bundle update then bundle clean cycle in ProjectA, won't that delete all the gems it doesn't recognize from ProjectB that I may need to work on later that day?

Or say I no longer want to work on ProjectA and want to delete the project and all gems associated with it?

Perhaps I'm approaching this the wrong way?!? Hoping someone can set me straight because everything else about rbenv seems simple & makes great sense!

Meltemi
  • 37,979
  • 50
  • 195
  • 293

1 Answers1

6

I am not sure about the mechanics of bundle clean, but it sounds like it does introduce the possibility of removing gems associated with other projects.

You have a few options:

1. You can let all the gem versions live in ~/.rbenv/... and just let Bundler manage them all for you. Old/stale gems will exist. (I currently do this.)

2. You can use a plugin like rbenv-gemset for more isolation. (or switch back to RVM.)

3. Bundler also lets you specify a path where to install gems, you could install them inside a projects directory (ex: /myapp/vendor/).

# Per project
bundle config --local path vendor
bundle install
# Saves configuration to /myapp/.bundle/config

# Global
bundle config --global path vendor
bundle install
# Saves configuration to ~/.bundle/config

There could be alternative ways to deal with this, but these are all of the methods I'm familiar with.

codyeatworld
  • 1,263
  • 7
  • 9
  • I guess my worry with #1 is that over time `~/.rbenv/...` will become a bloated mess of obsolete gems. But I guess as projects that are still active eventually get migrated to new versions of Ruby their bundles will move as well so once all (or enough) projects move on from an old version of Ruby all those gems could be destroyed… is that sane? Not many devs *I* work with use `/vendor` though that could work if you add it to `.gitignore`… – Meltemi Aug 26 '16 at 00:48