I am not sure what the differences are between these two tools. There seems to be a big overlap, but I have been using RVM and facing some miss-compatibility issues.
What does Bundler do that RVM does not?
They serve different purposes. RVM creates a sandbox to manage your Ruby installations. As a part of that, it also lets you define gemsets.
Bundler doesn't manage your Rubies, it works with the currently selected Ruby.
So, I think you should consider RVM as the configuration manager for your development environment, and Bundler the gem manager for an application.
EDIT: Additional thoughts -
Whether we use RVM or not, typically we'd have to load all the gems we're going to use for an app by hand, using gem install blah, for every gem we want to use.
I end up managing my gems across multiple Rubies by hand. Once they're installed I can create gemsets using RVM, but RVM won't automatically retrieve a particular version of a gem if it's not installed, or go get it again if it was removed. Because RVM is more concerned with your Ruby environment, it mostly leaves the versioning of gems to gem and to us.
Bundler, on the other hand, does care about those missing parts in RVM. When you create the Gemfile for bundler, it will retrieve the necessary gems and specific versions if specified. So, the task of installing a Ruby app on a different machine becomes much simpler. Push the files to the other machine, then run bundle install and it'll do the rest.
It works nicely with Rails and is a sensible solution for my production files. It will be much simpler than how I have to handle Perl distributions in order to run Perl apps on the same hosts.
RVM is more like a containment unit. While Bundler is like a manifest (dependency manager) of what the application will require or use in it's lifecycle (among other things).
If you are working in Rails, you will not be able to escape Bundler. But I use it all the time just so I know what Gems I'll need, and so will others who later come into the project.
RVM helps me separate out my Rubies and then further into Rubies/projects. This way I don't have a slew of Gems and different versions all in one pile.
Not exactly the most action packed answer, but hope it helps a little.
To directly answer your question...
What does Bundler do that RVM does
not?
Bunlder will install all gems that are needed by a project (that uses bundler, and have all needed gems specified in a Gemfile). RVM does not do this.
Using the Gemfile you can specify what gem groups (ie: development, testing)...
There are many 'small' things like these that bundler does but RVM does not. In general as the good people above explained, RVM has a different set of goals from that of bundler. RVMs about managing ruby runtimes while bundler is about managing dependent gems for a application.
Bundler is a tool for managing dependencies in your code -- i.e., all the gems it requires. It will make sure that all the gems you specify in your Gemfile, and any dependencies, are installed on your system. It doesn't really care which version of ruby you are using, it just installs the gems for you under whichever interpreter is in use.
RVM is a tool for running multiple rubies, and in theory, multiple gemsets as well. It doesn't handle dependencies for you at all -- it's still up to you to install the gems.
My experience (and I'm new to RVM), is that you don't want to bother with RVM unless you have a need for running multiple rubies, or need gems installed for different projects that somehow conflict with each other. Even if you are using RVM, it makes sense to use Bundler to manage gem dependencies so that your Gemfile can be tracked in whatever code repository you are using.
Related
I'm learning ruby recently and I'm a front-end developer, I found the dependecies are installed to C:/Ruby31-x64/lib/ruby/gems/3.1.0 folder when I use bundle install. it seems dependencies are installed globally by default like the npm install -g. I know that Bundler also have a way to install the gems to the local folder, so I wonder is
it recommend to install the dependencies to the local folder like npm does?
Similar to Composer, Bundler takes care of maintaining your dependencies, but rather than installing everything in the project folder, it distributes your gems system-wide, which are then shared by all of your projects. Using the Gemfile in your project folder, it keeps track of which libraries each project needs. Bundler is the default package manager for Rails, so you should simply let it do its thing. It does it quite well.
Hope this helps.
Use a Version Manager for Ruby, and Bundler for Gem Version Management
There are occasionally reasons to install gems in from one another isolation, but most often you should use a Ruby version manager to manage your non-system Rubies and Bundler to handle multiple gem versions and locations. Avoid modifying your system Ruby or its gems whenever possible. Also, be aware that even using RVM gemsets (or similar features in other version managers) without tweaking some poorly documented features like rvm gemset globalcache enable can create a level of isolation that is likely unnecessary and can bloat disk usage dramatically.
If You Need Gem Isolation...
That said, if you want to ensure you are isolating your gems or localizing them to your application and aren't using direnv's Ruby layout to manage all the various environment variables involved, you can use Bundler's BUNDLE_PATH environment variable to "vendor" your gems into the local application directory (these days usually under vendor/bundle). For deployments or containerization, you can also invoke bundle-install with the --deployment or --standalone flags and a list of gem groups to install if you don't want to rely on the availability of Bundler itself after installing the gems.
This sort of thing might be useful for building containers or tarballs, but isn't really very useful for development. Don't do it unless you have a really strong reason.
I am writing a dev command-line tool gem (let's say called "tool") which I would like to use in any place in the system. I use RVM for different projects, but this tool should be available from the command-line inside those projects.
If I simply install the gem globally using "gem install" (let's say it installs to /usr/local/bin/tool), the executable is of course available inside of other projects, but since the gemset changed when executing "tool" it fails saying that it cannot find the "tool" gem (because "tool" was never installed to that gemset). I don't want to add the gem to all the Gemfiles of all the projects.
What's the best way of dealing with this? Perhaps there is a way to "lock" the gem_path/gem_home in the executable at the time of installation?
It turned out that https://github.com/sportngin/brew-gem does what I want, installing a Rubygems gem via brew and locking its GEM_HOME and GEM_PATH in a bin wrapper it generates, so that everything works even when executed in the context of a different RVM gemset.
I forked it into https://github.com/gtmax/brew-gem, adding support for installing a brew gem from a local.gem file or from a gem project on github.
Apologies for the topic title, couldn't resist.
Basically, For no reason whatsoever apart from trying out different things. I want to implode RVM and try out rbenv. Nothing against RVM, just want to try different peoples software and try different things out.
I can get rid of RVM and install rbenv no problem. Could you guys confirm a few things for me.
Firstly, if I do the above, and then install a few different ruby versions. I know I can place a .ruby-version file in a projects root directory to specify a specific ruby version but then when I say gem install <gemname> I take it that is installed globally for that ruby version.
If I then use bundler per project to manage what gems are used and I specify a gem version, what happens if the version specified in the lock file is different to the currently installed version and what happens if it's vice versa?
I just need a bit of clarification on what's doing what in regards to ruby, versions, gems and their versions.
One of the (many) lovely things about rbenv is that you can so easily look right at your ruby installation to see what's going on. For example, on my machine I can open ~/.rbenv and there's versions containing my ruby installations, such as 1.9.3-p327. Opening that, I can keep drilling down to see my gems installed for that version of ruby (in ~/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems). It is then trivial to run gem list or gem install somegem and confirm that what's being affected is this very collection of gems - if this is the current ruby (set in rbenv global and starred in rbenv versions).
In short, everything about your system thinks that ruby means this version of ruby and that its library is this library.
For Bundler, you'll need to install rbenv-bundler. A nice tutorial (easily found with Google) is here: http://dan.carley.co/blog/2012/02/07/rbenv-and-bundler/
The rbenv documentation states that you can use the gemsets plugin to sandbox your gems if you aren't using bundler:
Manage gemsets. Bundler is a better way to manage application dependencies. If you have projects that are not yet using Bundler you can install the rbenv-gemset plugin.
However, I am using bundler and when I switch between projects that have different gemsets I need to re-bundle. When I was using rvm, this was simple due to the .gemsets file.
Is there a sandboxing functionality in bundler that I am not aware of or have I misunderstood the documentation?
I found this clear, well-documented solution:
Setting up and installing rbenv, ruby-build, rubies, rbenv-gemset, and bundler
Now when you gem install (see “Bundler” section below) something it will go to your helloset gem area.
You can combine use of multiple gemsets with it.
The big benefit to this setup is enabling each project to use a different set of differently versioned gems.
Read the section entitled Enable RVM-style “gemsets” (optional).
It uses the rbenv plugin for gemsets: https://github.com/jamis/rbenv-gemset.
Update 8/12/2012 I am using this to manage two projects with different versions of Ruby, and separate sets of gems. It works well.
bundler uses the Gemfile and Gemfile.lock files in, in essense, to make a "gemset" for that particular project that you access via commands prefixed with bundle exec
It may have to do with the way rbevn uses shims. You might want check out
https://github.com/carsomyr/rbenv-bundler
Try using chgems with Bundler. chgems is like chroot for RubyGems. It spawns a new sub-shell with PATH, GEM_HOME and GEM_PATH updated to use $project/.gem/$ruby/$version as the primary GEM_HOME. Since all gems are installed inside of the project directory, cleaning up after a project is as easy as rm -rf $project/.
I have JRuby and Ruby (MRI) installed. It seems that I need to install gems twice - once for each of these platforms. Is this necessary or am I doing it wrong? After I installed the rails gem for MRI, should I have pointed JRuby to it, or was it necessary for me to also call: "jruby -S gem install rails"
You need to install gems for each different install of ruby that you have.
If you set GEM_HOME you can share your gem installations.
Some gems target specific platforms, e.g. Mongrel (there's a MRI one and a JRuby one). Also, JRuby cannot use gems that have native extensions (i.e. C code) unless they use the FFI (which most do not - yet).
Personally I have separate gem repos for MRI and JRuby. The little bit of extra hassle is worth the peace of mind when trying to track down a problem.
It's pretty easy to see what each repo has installed:
jruby -S gem list --local
vs.
gem list --local
You could even write a ruby script to sync one gem list to the other, but you'd have to be careful about platform specific gems....
I hit this problem when creating my gem, jimmy_jukebox, but made my gem work with both.
First, JRuby doesn't handle fork...exec (and even replies incorrectly to Process.respond_to?(:fork)), so I had to rescue NotImplementedError and use Spoon.spawnp instead.
I then created (in my gem's /bin directory) paired executables -- play_jukebox and jplay_jukebox; and load_jukebox and jload_jukebox -- each with the correct shebang line (/usr/bin/env ruby or /usr/bin/env jruby).
I'd love to know a better way. But I'd rather handle everything within a single gem than maintain and distribute multiple gems.