It causes so many deployment issues it's ridiculous. Most of the time I don't care what version of gems are used, just want to use the latest one.
UPDATE in response to comments:
Here are a couple of examples off the top of my head:
developer A is using a pre-release of a gem so when he runs 'bundle update', the Gemfile.lock is messed up for everyone else and if you deploy it, there goes your site.
A bug in a gem gets fixed so we run gem update across our servers, restart rails and yay, bug fixed! Oh, but wait, it's not fixed? Thanks bundler. What should have been an easy fix is now a full code deploy across our servers.
That's just a couple off the top of my head. At least let us decide if we want to lock in gem versions or perhaps at least allow a range of versions for instance any 2.X version.
UPDATE 2: And yet another issue when there are windows developers on the team
Here is what's showing up in a windows Gemfile.lock:
nokogiri (1.4.4)
nokogiri (1.4.4-x86-mingw32)
Wow, this is just awesome. Sure makes for easy teamwork and deployment.
I recommend starting to use two techniques with your development and deployment:
Specify version number of gems in your gemfile.
For example:
gem "rails", "3.0.1"
gem "will_paginate", "~> 3.0.pre2"
This way, when you decide you want to update rails, or will_paginate, change the version numbers in your gemfile.
Only update certain gems
Rather than the generic bundler update command, run
bundler update rails
This will only update the rails gem to the newest version, rather than get the latest of all gems.
If you use both 1 & 2, you'll have a happier experience.
Then, simply, don't check your Gemfile.lock into source control. All of the specific problems you listed are solved.
Of course, you are sacrificing the enormous advantage that Bundler gives you over any other dependencies management system.
Related
What is the use of Gemfile in rails?
How to use Gemfile?
During your development in Rails, there will be times where you will want to provide some functionality which is required by you, but either you don't know how to do or you don't want to implement it on your own since a lot of work has been put into its development by talented developers.
These developments which you might need (user authentication, message system, asset handlers, geolocation, pagination system, linking to exterior services such as Amazon AWS, and last but not least Rails itself) are called Ruby Gems. These are ruby software packages, not necessarily relating to Rails, but since Rails is based on Ruby, 98% of the gems can be made availble to your Rails webapp code.
Lots of gems can be found in github, but its funner to search for gems via ruby-gems or ruby-toolbox
Your gemfile is a list of all gems that you want to include in the project.
It is used with bundler (also a gem) to install, update, remove and otherwise manage your used gems.
The gemfile has another purpose - you can group gems in :development, :test, :assets, :production, etc groups and Rails will know when to include the gems. For example:
group :development, :test do
gem "rspec-rails"
gem "factory_girl_rails"
gem "guard-rspec"
end
Note that on Rails 4, the assets group has been deprecated
These gems belong to development environment and the test environment since they are for testing the application. You don't need them available in the production environment (you could, but that will bloat the memory unnecessarily).
So - To use the gemfile, simply write the gem you wish to install such as
gem 'devise'
make sure to install bundler beforehand (in your console/cmd/ssh) with
$ gem install bundler
and then write in the console
bundle install
you will notice another gemfile appears! Gemfile.lock
This file, as you will see if you open it with a text reader, lists all your gems with their version and their dependencies. This will come useful when you need to know which versions of the gems you installed.
For more reading on the Gemfile - read on the bundler page
for information regarding picking a gem you could start with this
Good luck and have fun!
Ok, so whats this Gemfile.lock that got created?
Gemfile.lock, as the name suggests is a locking on all the versions of all the gems that got installed. So if Gemfile is what required to be installed, the lock file is what got installed and what version are actually required to get the app up and running.
If you don't have the gems in that specific version (as specified in Gemfile.lock) rails will complain and you will have to either install the missing gems (via bundle install) or fix any conflicts manually (I believe bundler will give you some clues on that)
Some things to know about Gemfile.lock
if you accidently delete it, it will get regenerated when you run bundle install. If you accidently delete Gemfile, you are out of luck.. You should use git :)
Heroku doesn't care about Gemfile.lock since it will reinstall all gems. So for Heroku, you must set the gem version you want, or Heroku will always install the latest version of gem, which may cause issues
Keep the Gemfile.lock in your project so you will always know what version of gems make your app work properly.
Gemfiles are configuration for Bundler, which is used to manage your application's Ruby dependencies. That website includes a lot of documentation, including the Gemfile manual page.
Explanation by analogy
You want to build a car. From scratch. You need to build: a chasis, engine, corroborator, radiator etc.
Gems allow you to utilise car parts which other people have made before
Everyone's who's ever built a car has needed the same things.
You needn't reinvent the wheel. Why make your own engine etc when you can get it straight off the shelf? What if you could get one of the best engines around, created by the most talented engineers in the world, without lifting a finger? Are you gonna spend a year trying to make your own?
So basically rather than make everything yourself, you write down a shopping list of all the parts you need:
Rolls Royce Engine
AutoLive seatbelts
Michellin tyres.
PIAA Night headlights
etc etc.
That my friend, is basically your gem file!
Your system can have lots of gems ... thus can have multiple versions of same gem.
A Gemfile specifies the list of gems with their versions that shall be used/loaded/(install if not present) whenever you run your rails application. or anything with bundle exec . .
Firstly, what is a gem?
According to Wikipedia:
RubyGems is a package manager for the Ruby programming language that
provides a standard format for distributing Ruby programs and
libraries
Gemfile
A Gemfile is a file we create which is used for describing gem
dependencies for Ruby programs
Now, in very very simple words:
Gem can be thought of as a library which you can use in your code.
Example: faker gem
Your code can use the functionality of faker gem to produce fake data.
Now you can list all the gems that your project requires in the gemfile.
When you do a bundle install, all the gems in your gemfile are installed for you.
My question is very similar to How do I freeze gems into a Rails 3 application?, but I only want to freeze a single modified gem. The answers to that question seem to result in bundling all the application's gems.
In case it's relevant, I need to do this so the modified gem gets installed on Heroku.
I checked the bundle-install doc but it didn't seem to address this situation. I can't imagine it's that uncommon, though. Any guidance is appreciated.
Well, Bundler is going to freeze all of them, and the idea is that you want to freeze not only a single gem, but the collection of gems that produced a working copy of your app.
That being said, on your local dev machine, you can do bundle update [name of gem] and it will update just that one gem to the latest version within the restrictions specified in your Gemfile, which also updates your Gemfile.lock, which effectively updates just that one gem on Heroku when you next deploy.
If you're using bundler, which is the default for Rails 3, you can always fork the gem to your own git repository and add that definition to your Gemfile with whatever location it can be found at:
gem 'thegem', :git => 'git://github.com/cloned_to_me/thegem.git'
Another option is to use bundle package to save copies of the gems in vendor/cache. These can then be later installed using bundle install --local according to the documentation.
This is the closest thing to the Rails 2 "freeze" method, but has the added advantage of saving the gems before they are installed, not after, avoiding any platform-specific problems as was the case previously.
With thanks to those who answered the question with related approaches, I ended up going with the approach mentioned in this sister question. For the sake of clarity, this is what I did:
Repackage modified gem as its own gem. This takes a little finagling but is described well in the RubyGems Guides. Move said gem into your source directory (I used vendor/gems)
In the project's Gemfile, point to the location of the new gem:
gem "modified_gem", :path => "vendor/gems/modified_gem"
Add new gem to version control, make sure bundle install isn't messed up with funky settings (e.g. --local), and cross your fingers.
Someone also mentioned that it's possible to mix in changes to the gem instead of overriding source files. I don't know anything more about this technique except that it should be possible.
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.
Using Rails 3, I'm trying to figure out what I think should be pretty straightforward...
I have 2 gems that require 2 different versions of the same gem dependency. Both versions of the dependent gem are installed on my system but I still get an error from Rails: "Bundler could not find compatible versions for gem XXX".
What is the best practice to handle a scenario like this?
I'd go for what #BaroqueBobcat suggests. I just want to add that - if you need the latest Twitter gem and can't wait for the maintainer of Groupon2 to update his gem - you can fork the Groupon2 on GitHub, update its gemspec, see if it still works by running its tests (and try to fix it if it doesn't) and include your own version using its Git URL in your Gemfile like so: gem "groupon2", :git => "https://github.com/yourgithubuser/groupon2.git".
If you want to be nice you can offer your changes to the maintainer of Groupon2 with a pull request for bonus points :)
If you don't need all the features of the Twitter gem version 1.4.1, you could use version 1.2.0, which needs faraday ~> 0.5.4. and that should work. If that doesn't, you could try
poking the owner of groupon2 to update his gem--it's on github https://github.com/gangster/groupon2
.
I was having the same issue, but in a different context: Writing an app which uses two different versions of the hashie dependency (1.2.0 and 3.1.0)
I went into the Gemfile.lock and specified the older version in parentheses hashie (1.2.0), ran bundle install, and it worked.
If you're in a situation where the gems are being used in different projects or at least not at the exact same time you can use RVM's gemset feature as a workaround. I recently had a gem incompatibility similar to yours and that's what I used.
If you have RVM installed, do this:
rvm gemset create gemset_name_here
rvm gemset use gemset_name_here
So what you're doing is creating a gem environment that's totally fresh and from scratch while still being able to revert back to the gems you were working with before at any time. The first line creates a new gemset and the second line tells RVM to start using it.
At this point you'll need to run bundle install or rake or whatever you're using to get the gems you need but this should take care of the problem.
So when you're using gem 1 with dependency 1 you use the gemset that has the required version. Then when you're using gem 2 with dependency 2 you switch to the gemset that has that.
Now, if both gems are part of one larger project this will not be feasible and you'll most likely need to edit the source to of the gem to run the new version of the dependency like #BaroqueBobcat said. In a lot of cases this is actually pretty easy. Ruby developers tend to be very awesome about making their code easy to pick up on.
Take a look at this solution, maybe it will help you: gems
bundle update resolve conflicts
What is the difference between installing a gem from the command line
sudo gem install gem-name
and writing your gem into the Gemfile and running bundle install?
I think the problem is that I don't understand the exact purpose of the Gemfile. So far it seems like it is a place to list all of the gems that your app is dependent on.
Installing a gem via:
sudo gem install gem-name
is going to install that gem system wide.
Whereas installing them via the Gemfile is specific for your rails app(to keep track of dependencies, version, app portability etc).
The best source of the whats and whys about Bundler, is probably this page:
http://gembundler.com/rationale.html
That page has great examples and explanation about why Bundler is useful and in some cases, necessary.
I always thought you write all gems that your app is dependent on in it, and then if you want to port your application somewhere else, you can run the bundle install and it'll grab the gems you need for you so you don't manually have to do it.
This might clear things up, I quote:
'It holds information about all the project dependencies so that you don't need to struggle to figure out what gems you need to install.'
http://blog.despo.me/42762318