Just a bit of background, I come from a strong C#/staticly typed background. Therefore I tend to think in terms of .dlls. So if I was working in a project, I'd reference my required dlls and that would be that.
Being new to Ruby and Rails I find I might be doing something wrong. For example, I create a Rails app at home using the gems I have locally. Using a different computer (say a work computer) I attempt to work on the project only to find I'm using different versions of the gems. After carrying out a bundle install I'm back to a working project.
The issue I have with this is that my gem library becomes 'messy'. I end up with several versions of the same gem. Is this the way others work? When using a gem (from a require) will it default to the latest version? I feel as if I'm not managing the dependencies correctly, though as I've mentioned I'm new to the world of Ruby.
Should I just include my dependencies, then perform a bundle install each time I have different/missing dependencies? What happens if I wish to upgrade to a newer version of a gem? Would it be a case of updating the gemfile that bundle uses and getting on with it?
Yes, bundler is the way to go to work with dependancies with Ruby on Rails. Why ? First, because it's shipped with it (at least for version 3.0). Second, because it's simple as hell (unlike maven with Java).
A non exhaustive list of feature :
it lets you declare one or many gem repository to fetch gems from
to group your dependencies by environment (development, production...)
to specify version you'd like
and so on. For more on this, check this http://gembundler.com/rationale.html
Regarding your question : yes, bundler will take the latest version available is none is specified.
Also, I would add a disavantage : you cannot specify a gem version depending on the OS. For example, nokogiri has a linux version AND a win version.
The default behaviour when requiring a module in a gem is to assume you want the latest version of the gem if you have more than one installed. You can change this by specifying which version you want in a specific application like this:
gem "rails", "2.3.8"
Before you require anything from the gem. This ensures that this application will use the specified version of the gem, even if a newer one is installed.
You can of course clean out obsolete versions of your installed gems whenever you don't need them again, or if you use bundler consistently: just wipe everything and run bundler again to get just your required gems installed.
Another useful tool is the Ruby Version Manager (RVM), in addition to handling different versions of ruby it provides a feature called gemsets which allows you to isolate different applications or environments from eachother. That is App A can have its separate gemset with all its required gems, and App B have another gemset with only its required gems. This will reduce the clutter in your dependencies quite a bit.
Related
I am new to Ruby, Rails and gem management. One thing what I have noticed is that whenever I run bundle install (even within the project directory) it seems to install gems which affects other gem based Rails projects too.
For instance, assume that after running bundle install within one gem based Rail project (which installs a bunch of gems from the gemfile) I run into gem incompatibility issues. Now, these issues will manifest in all the other gem based projects too and will present themselves everytime I attempt to rackup
My questions are:
1) Is there a way to localize this damage (gem version incompatibility) to the current project and not have other projects affected?
2) Is there a good way to obtain a compatible set of gems or is the only way to look at the gem dependencies on a gem-by-gem basis (look at the tree) and figure out the compatible ones? I seem to be wasting a lot of time on this and if I fix one something else seems to break.
Please let me know what I'm missing here or point me to resources.
Thanks
It sounds like you're missing use of bundle exec
Description
This command executes the command, making all gems specified in the Gemfile(5) available to require in Ruby programs.
Essentially, if you would normally have run something like rspec spec/my_spec.rb, and you want to use the gems specified in the Gemfile(5) and installed via bundle install(1), you should run bundle exec rspec spec/my_spec.rb.
bundle install will install gems to $GEM_HOME which is shared by any apps using the same ruby and can result in multiple versions of the same gem being installed (this is expected and normal). If you don't then also use bundle exec to load only the gem versions specified in your Gemfile you can get incompatibility errors or unexpected behavior as ruby doesn't know which version of a particular gem to require.
RVM, rbenv, and other ruby version managers are useful tools for both isolating gems per project (which isn't really necessary when also using bundler) and for allowing multiple ruby versions to be installed on the same machine (which is not handled by bundler and can be very useful when developing multiple apps with different ruby version requirements).
Given we use a preferred flavour of a ruby version manager (RVM or Rbenv) the ruby gems are isolated per ruby version.
Let's say we want to work on multiple applications locally (they are completely separate applications) and we want to use the same ruby version and the same rails version how do we properly isolate them and their gems? Are gemsets the (only) answer here? I mean if I have 5 applications with the same ruby version and I keep adding gems on all 5 fronts it's just a matter of time when one of the applications is ok with the latest stable gem version while one of the apps will still need to roll on an older version of the same gem due to legacy dependency or whatnot. How do you guys avoid this timebomb?
What if we want to use the same ruby version on multiple apps but a different Rails version? Rails being 'just a gem' is the answer same as for the above?
Thanks.
I'd recommend to use:
rbenv to handle multiple ruby versions on the same machine
bundler to define the dependencies of each application
Make sure to push .ruby_version, Gemfile and Gemfile.lock to make sure every is using the appropriate version of each gem...
I have two Sinatra apps, each using a different set of gems, and some of them have conflicting versions, e.g. app A uses Nokogiri 1.6.3 and app B uses Nokogiri 1.5.5.
How do I manage those two environments on the same OSX machine and be able to switch between them without conflicts?
Can I use only Bundler for that, or will I also need RVM? How exactly?
Bundler Handles Multiple Gem Versions on System
Bundler can handle this use case just fine. Your explicit gem dependencies go into your Gemfile, and all gem versions within the bundle are then stored in the Gemfile.lock file.
As a general rule, your gems will be installed in GEM_HOME. Multiple versions of a gem can be installed at the same time, and require bundler/setup takes care of ensuring that the correct versions (as specified in your Gemfile.lock) are made available to your Ruby application.
However, unless you use binstubs, gemsets, or special invocations like <gem> _<version>_ [args], you will need to run bundle exec <gem> from the command line in order to use the correct version as specified by your bundle.
The best way to manage multiple applications on a system is to use a manager like RMV (Ruby Version Manager).
RVM has the concept of a gemset, which you can use to create different sets of gems for different apps. It is the solution of your problem. You will need to create different gemsets for both applications. Like this, your gem versions will not conflict.
I want to know should I specify gem version for each gem I add to Gemfile or not. Earlier with few of my projects I didn't specified any versions for all the gems and bundler took care of it, which worked quite well as well.
But recently I got to work on few project which were under development for last 6 month. In that project, many of gem versions were specified in Gemfile only and Gemfile.lock was ignored. That caused a lot headache to finally resolve version conflicts and upgrade few gems.
Also got to know that it's bad practice to remove Gemfile.lock from application version control - nice article by yehuda - http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
So, my question is should I specify version for each and every gem I specifiy in Gemfile or just specify name and bundler will take care of version ? What is best practice to handle this ?
UPDATE -
Updating this question to correctly specify the problem, as a Gemfile sovles many problems :)
Prob 1 - Every developer should have same version of gems.
Actually adding Gemfile.lock into version control solved this problem. Developers just have to take care that they run 'bundle install'/'bundle' rather than 'bundle update' as this will update versions as well.
Prob 2 - Some gems version, if changed, brakes application code.
Actually with omniauth,there are this type of issues, as API are changed from one version to another. And yes, to keep application working, versions will need to be specified for this gems.
My Prob. -
So, in my gemfile, as versions for both A and B are strictly specified, and as they both depend on different versions of Z, which is there dependency, I even can't run the bundle install or bundle update. The only solution was to remove versions and let bundler to take the call. That's why I had question like -
Gemfile.version_specification_mandatory? #=> true/false
I think it's best to not specify gem versions in the Gemfile. On rare occasions, it may be necessary to specify a version--e.g., when a newer version breaks your app. But specifying versions for all of your gems is usually overkill. The Gemfile.lock file (which you don't edit, but you do check into version control) will keep newer releases of gems from being used in your app, until you explicitly upgrade to them.
If you are using the gem for something that is available only in a specific version, you need to specify the version.
Bundler installs the latest version or uses the available version on the system if no version is specified. This works for the developer because the latest version has the feature she needs. But if the feature gets lost in the future versions of the same gem and the version is not specified in the Gemfile, all subsequent installations of the gem for different people or different machines will produce undesired effects.
I have faced these problems particularly for will paginate 3's release candidate versions.
I don't recall how Bundler worked back in 2011, but in 2021, if you don't specify a version in your Gemfile, you can't assume that Bundler will always automatically install the latest version. Instead, Bundler will try to find the right combination of versions to make all your gems compatible with one another. This could lead to some gems being downgraded, which is probably not what you want or expect. Bundler will do this silently, without a warning message, which you could argue is a broken user experience.
On the other hand, when you specify a version, if there is a conflict, Bundler will let you know and you can then decide how you want to proceed.
I recorded a screencast recently to show a real example of an older version of a gem being installed when the Gemfile didn't specify a version number.
I am facing some problem with rails gem when deploying to a differet machine.It requires some extra work on installing gem.Which is most suitable for a rails project.Plugin or Gem.
For Some gems there is no corresponding plugins found.
I am searching for advantages of using plugin over gems and vice versa.
You can unpack gems to your Rails application, which will make sure that they are deployed together with your application:
rake gems:unpack:dependencies
Now you no longer have to install the gems on the server you deploy to. This already takes care of most of the deployment issues. Most others are solved by Bundler, which will be included with Rails 3.
If you can, use gems over plugins. Gems are generally easier to manage, because their versioning is superior to plugins. For public Rails extensions, I see no reason to use plugins instead of gems, but some authors only offer one of the two. In that case you have no choice.
I usually always use a plugin if it is available as it gets frozen into the project, meaning there are no issues when the project is deployed. You can freeze gems into a project but if they require a native build it causes more hassle than it's worth from my experience.
My understanding is gems are easier to upgrade than plugins.
You should also look into the rails 3 bundler which is used to handle these deployment issues.
For me, plugins are preferred. I've run into many a situation where I'll have an improperly configured environment.rb and gems won't have versions assigned to them. Then the server admin does a:
sudo gem update
And now my rspec tests won't run because the update installed test-unit 1.2.2 and my specific setup needs 1.0.1 (or something).