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
Related
I'm a new Rails developer. I recently took a class on Rails and now I'm trying to make sure I'm growing in my skill by self-assigning projects that push me. One thing I'm trying to do now is use Radiant CMS to build a blog site. However, I'm running into some problems downloading the Radiant gem. Here's what I did:
When I first tried gem install radiant, it installed most of the required gems but then threw a warning (which I unfortunately did not save verbatim), which was along the lines of:
railties executable will overwrite rails executable. Overwrite? Y/n
Stupidly, I chose "Y". As soon as I did I tested my rails gem by writing rails new testproject and it failed. So I then re-ran gem install rails, told it to overwrite the "railties" executable, then ran gem uninstall radiant to get rid of the core radiant gem (although I do still have railties).
Now, my Rails gem is fixed, and I can create new Rails projects without an issue. However, I reinstalled the Radiant gem, and while it installed, it fails to create a project every time I run it.
I'm pretty sure I broke something, but I'm not terribly concerned about that. What I am concerned about is the fact that it seems that the Radiant gem doesn't really coexist well with the Rails gem, which leads me to my question:
Is there any way to create separate, self-contained ruby gem environments where the current Ruby version will only use the gems in the specified environment?
In essence, I'm looking for what rbenv does, but for collections of gems rather than Ruby versions.
Currently, I have Homebrew installed and I am using rbenv as my version manager. Everything I can find so far talks about managing gems on a project-by-project basis; I'm looking for something that will manage and keep separate the gems that create the projects in the first place. So, for example, environment_a contains rails and httparty while environment_b contains radiant and railties.
I'm not above completely obliterating rbenv and all of my gems and starting from scratch, either, so that's a possibility (and an advantage of being a noob).
You should check bundler, as it does exactly what you need.
Yes: rbenv-gemset
I think that it is better than RVM because it is less invasive.
I have been using rbenv and rbenv-gemset for about 2 years and find it easy to use. It makes it easy to encapsulate the Ruby and gemset in a project, run multiple Rubies and gemsets on one machine, and move a project to another machine.
You can use ruby-build to install other versions of Ruby. There is a trick to installing the latest versions of Ruby.
You may want to have a look at How do I ensure ruby gems are installed in right place to be executed by bundler? It has some relevant (and hopefully useful) info.
Yes, there is.
I think that it's called RVM.
Just like Chris Heald said, You can check more information about it # rvm.io/gemsets/basics
I'd recommend bundler for versioning gems although both RVM and rbenv also have this functionality.
You asked: "Is there any way to create separate, self-contained ruby gem environments where the current Ruby version will only use the gems in the specified environment?"
The best way to do it with rvm is entering your project's directory and then run:
rvm use ruby-x.y.z#your_project_name --ruby-version --create
where x.y.z is your Ruby version for that project, previously installed with rvm install x.y.z
For example, to use the newest Ruby version with a project named acme you would use
rvm install 2.3.1
and then
rvm use ruby-2.3.1#acme --ruby-version --create
This command would create two files in the projects directoty: .ruby-version and .ruby-gemset.
The file .ruby-version would contain just the version number. And the file .ruby-gemset would contain only the name off the gemset, the same name of your project (acme).
It happens that rvm is smart enough to check for these files and use the gemset specified, which will be located at ~/.rvm/gems/ruby-2.3.1#acme and your gems will be located at ~/.rvm/gems/ruby-2.3.1#acme/gems.
Some points:
1) Using your project's name as the gemset name is NOT mandatory. You may use anything you like. It's kind of a standard using project's name, but not mandatory.
2) rbenv probably has a way to do the same, but I don't use rbenv and really don't know how to do that.
Hope this answer helps.
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.
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.
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.