I'm using RVM to manage the different ruby versions I have. One particular application is using an older ruby version (2.3.1), and I've noticed that, once I've changed to that version and run rails server on it, it doesn't work because I'm required to change a whole cascade of Gems or other files, such as nokogiri, to make it run.
Generally, from what I've read online, I should just do a simple bundle install to do all of this before running rails server. However, it doesn't work as there are more conflicting things in this file, specifically that the versions are hard coded into it.
Based on this, how can I run this app on my local server, if the above steps I've done, just doesn't work? I'm using Ubuntu, if that helps.
You're dealing with what is known as dependency issues. The point of Gemfile and Gemfile.lock is to insure that there will be no dependency issues for the application and bundle install will handle that. However it is common for versions to be set in the Gemfile to lock to a specific major release version which might allow for minor version updates. This will look something like:
#Gemfile
gem 'rails', '4.2.10'
gem 'pg', '0.20.0'
gem 'after_party', '~> 1.10' #minor version updates will run here
gem 'kaminari', '~> 1.1'
ruby '2.3.6'
This ia a brief example. Now when you run bundle install it will make sure everything is compatible with these versions. While running bundle update will only update the versions with ~> before the version and will upgrade only minor semantic versions as they are not supposed to have breaking changes.
So, why is your app not working? Well the Gemfile should have contained a ruby version. RVM should determine your ruby version in .ruby-version file in base of your rails app and should match the version in Gemfile. If you need to upgrade your ruby version bundler will help insure all your gems are compatible with that version and with each-other. You'll first need to upgrade your ruby version with RVM, then set it in Gemfile.
However, there is no guarantee that out of date gems will be compatible. That's the whole point of locking them so that you know which versions are stable at a give point in time. Updates / upgrades to gems have to be tested for compatibility which can sometimes be a project.
Also see Rails Bundle, gems conflicts, best way to solve it
You can create a .rvmrc file or .ruby-version and .ruby-gemset files for isolating gems for your projects. Here's the official documentation on that - https://rvm.io/workflow/projects#project-file-ruby-version
you can add
echo '2.3.1' > .ruby-version and echo 'newgemset' > .ruby-gemset into working folder
then run
cd ./
rvm install ruby-2.3.1
gem install bundle
bundle install
Related
I want to get a Gem's version without running bundle install.
Which is to say I want figure out what version bundle is planning to install without actually installing the gem.
Say read it from the Gemfile.lock(and Gemfile) combined.
Is there a way I can resolve what version bundler plans to install?
I need this because I want to cache the expensive installs while running docker build.
Gems like rails(nokogiri) take a while to install and I would like to do gem install rails -v ... in a previous step before running bundle install.
For this purpose i need to get the rails version before hand
If you add a new gem to your gemfile, but don't do bundle install, it doesn't install yet. Instead, you can run bundle lock, which generates a new lock file. This includes the gem version of the new gem that would be installed.
By running bundle show new_gem, it shows it isn't actually installed.
To be sure maybe get a backup of the original Gemfile.lock before running the command though.
By default if no version is specified in the Gemfile, running bundle install will attempt to install the latest version of the gem which is compatible with the rest of the gems and ruby version in your project. This will create a Gemfile.lock file if one doesn't already exist. If a Gemfile.lock file is already committed to git repo, it should then install the versions specified in Gemfile.lock. The point of bundler is to handle dependencies to insure your stack works correctly.
To see the version of a gem bundler is currently using you can run
bundle show rails
You will probably want to specify the ruby version in the Gemfile for example
ruby '~> 2.5' #
You can specify exact version of a gem in the Gemfile like this which you should be able to rely on to be the version bundler will install so long as it's compatible with the rest of the stack. bundle install will throw errors if there are incompatible gem versions.
gem 'rails', '4.2.11' # this will always install only this version.
You may also use pessimistic operator (~>) to set for only minor updates
gem 'influxdb', '~> 0.6.1' # could go to 0.6.2 but never 0.7.0
You can also set minimum versions like this although it's probably not what you need for your question.
gem 'pg_query', '>= 0.9.0'
If you have a Gemfile.lock already in your repo you can see which version would be installed by running for example:
gem show rails
Which would show you the version and weather it or not it is currently installed.
For more info see bundle --help
I want to free up disk space in my production environment taken up by gems installed for old ruby versions. I don't believe bundle clean will work in this instance, because I don't think it cleans out the old gems for other rubies.
These gems are installed via capistrano and are installed in a custom location, rather than system wide. In my /path/to/my-project/shared/bundle/ruby dir, I see 2 subdirs - 2.2.0 & 2.3.0. Since I am now using ruby 2.3, is it safe just to delete the 2.2.0 directory? Is there anything else I need to do?
Use "sudo gem cleanup" to remove all previously installed gems which respecting all the dependencies be it on old version of ruby. You can see all the gems that ll be removed with command "sudo gem cleanup -d"
here is how you can remove a specific version of the gem:
gem uninstall (gem name here) --version (version number here)
Go to Gemfile.lock and delete all its content. Then you go to Gemfile and delete gems you do not want anymore. After, You type bundle install and it will install just the ones you want.
Like the title says, if I use a gem in one app (install it, add to Gemfile, etc.) do I still have to run gem install xxx in a new app?
Unless you're not using Bundler, you very rarely need to run gem install ... at all, actually.
More often than not, unless you're using different Rubies for each of your projects, all of your gems live in folders that get shared across all of the projects that use them. If you're using rvm you can see this directory by running rvm gemdir.
When you use Bundler, it will automatically handle loading the appropriate version of the gem in the (likely) case that you have several versions installed.
No.
In fact, for a modern (Rails 3+) app you should never need to run gem install (except, of course, for the initial gem install bundler rails that you need to do once), you should just add the gem to your Gemfile and then run bundle install. Let Bundler take care of dependencies and installing for you, that's what it's there for.
I tried reading the documentation but this still wasn't clear to me:
Suppose my I have the following statements in my Gemfile:
source 'https://rubygems.org'
gem 'rails', '3.2.2'
# Bundle edge Rails instead:
# gem 'rails', :git => 'git://github.com/rails/rails.git'
gem 'sqlite3'
gem 'json'
...
I'm trying to learn how to use Ruby on Rails this website: http://ruby.railstutorial.org/ and it says that I need to have the sqlite3 gem for this version of rails (3.2.2).
My question is: if I don't specify the exact version of the sqlite3 gem for the system to download when I run bundle install then will it install the latest version that works with the version of rails and ruby that I'm working with (suppose it's 3.2.2 and 1.8.7 p-352 respectively) or will it just download the latest version of the sqlite3 gem available whether it works with what I have installed or not?
I'm not really sure how this aspect of the Gemfile works and the documentation hasn't been clear or I haven't found where it explicitly says this or otherwise.
So, it will install the latest version of sqlite3 that is compatible with the dependencies specified by the other gems you've listed.
Say, rails said it only worked with sqlite3 that was greater than 1.0 but less than 4.0, it might install 3.9.5. I'm making all these numbers up, just an example.
In fact, I don't know if rails does specify any particular versions of sqlite3 it requires. Presumably 'json' doesn't either, since it's got nothing to do with databases. If none of the other gems you list specify any requirements for sqlite3, it'll just install the latest version available.
'bundle install' is using bundler, some more about how it resolves dependencies is here.
So bundler will download the latest gem that meets the requirements of all the other gems you list. Say you listed a gem A which required sqlite3 earlier than 2.0 and a gem B that required sqlite3 later than 2.1 -- 'bundle install' would complain and say it can't satisfy them all.
This relies on the gems own advertisements of each of their own requirements for the other gems they rely on though. Sometimes they can be wrong, or missing. It may be that rails doesn't actually specify what version of sqlite3 it requires -- since it doesn't actually require sqlite3 at all (you don't have to use sqlite with rails), this may very well be. In which case bundler can't do much but get the latest version of sqlite3. Which doesn't guarantee that version will work. But it can only do so much.
You also mention the issue of compatibility with specific versions of ruby, like 1.8.7-p352. Bundler is less capable there, you can't generally count on it knowing what version is compatible with a particular version of ruby (because there's not a great way for gems to express this in a way that bundler can use, alas).
But in general, things work out. If you don't know or care what version of sqlite3 (or any other gem) you want, but know you want one -- do what you did, run 'bundle install', see if it works. It probably will. If it doesn't, google the error message and you'll probably find someone explaining why it didn't and what you need to do instead.
PS: If that wasn't enough. sqlite3 is sort of an odd case, because while Rails is designed to work with it, it's not required. But Rails by default, when creating a new app with latest version of rails rails new my_app, will already put sqlite3 in your Gemfile for you. And it'll do it just like you did, without a version constraint. That's reason to feel pretty confident it will work fine. Note that in rails 3.2.2, rails new my_app will put some other things in your Gemfile that do have more specific versions listed, like gem 'sass-rails', '~> 3.2.3', because while those things aren't absolutely required for Rails (or else they'd be expressed as requirements and not need to be explicitly in your app's Gemfile), the rails installer knows that only certain versions will work.
Fairly new to Rails as well so correct me if I am wrong.
The Gemfile looks to the gems directory for the gems listed and has no impact on actually "installing" them. Performing a "gem install" command without a version will grab the most recent version listed no matter what your Gemfile says. When you "bundle install", that is when version-specific lookups happen in your gems directory.
Bundler always looks at your Gemfile.lock file first when you're doing bundle install. If you open that file, you'll see the gems as well as the version used by your application. This is convenient for existing projects because you're always sure that every other developer involved with the project will be working with the same gem versions.
If it doesn't find that file (i.e. doing rails new projectname), or the specified gem or version in Gemfile isn't consistent with Gemfile.lock, it will download the latest or specified version of the gem.
I am a beginner to Ruby on Rails and I am using Rails 3.0.9.
What is the difference between Gemfile and Gemfile.lock in Rails?
The Gemfile is where you specify which gems you want to use, and lets you specify which versions.
The Gemfile.lock file is where Bundler records the exact versions that were installed. This way, when the same library/project is loaded on another machine, running bundle install will look at the Gemfile.lock and install the exact same versions, rather than just using the Gemfile and installing the most recent versions. (Running different versions on different machines could lead to broken tests, etc.) You shouldn't ever have to directly edit the lock file.
Check out Bundler's Purpose and Rationale, specifically the Checking Your Code into Version Control section.
Usually we write dependencies in Gemfile as:
gem "nokogiri", "~> 1.4.4"
gem 'bcrypt-ruby', '~> 3.0.0'
gem 'uglifier', '>= 1.2.3'
..
Here you basically say: "I want nokogiri as long as it’s greater than version 1.4.4", etc. Now suppose that I have set up my Gemfile 8 months ago and I successful setup my app with this requirement. 8 months ago nokogiri version was 1.4.4. My rails apps was running perfectly without any problems with this version.
Now think I'm trying to build with the same Gemfile. But if we look at nokogiri versions we see that the current stable version has changed to 1.4.9. That means if we try to build, bundler will install version 1.4.9 of nokogiri (suppose we don't have Gemfile.lock).
What does it mean ?
As you see if you don't have any Gemfile.lock and run:
bundle install
then the currently used gems can be different at any time. Your app used the version 1.4.4 and it works 8 months ago without any problems, but if you try to build it now you get the version 1.4.9. Maybe it's broken with the latest version of nokogiri, the awesome feature you used with 1.4.4 is not more available, etc..
To prevent this kind of problem Gemfile.lock is used. In Gemfile.lock only the exact versions are written and thus only these will be installed. That means if you distribute your app with a Gemfile.lock, every machine will have the same gems installed and most important they all get the same version. This will give you a stable and common deployment stack.
How is Gemfile.lock created?
It is automatically created with the first:
bundle install
command. After that everytime you run bundle install, bundle will first look up Gemfile.lock and install the gems specified there. It's an habit to distribute this file among your projects to provide consistently and stability.
How to update Gemfile.lock?
If you're happy with the the latest version of your apps than you can update Gemfile.lock. Just reflect your changes to Gemfile. That means change the dependencies to the new exact versions in Gemfile. After that run:
bundle install
This will update you Gemfile.lock with your newest version of apps.
The Gemfile.lock
When you run bundle install, Bundler will persist the full names and versions of all gems that you used (including dependencies of the gems specified in the Gemfile(5)) into a file called Gemfile.lock.
Bundler uses this file in all subsequent calls to bundle install, which guarantees that you always use the same exact code, even as your application moves across machines.
Because of the way dependency resolution works, even a seemingly small change (for instance, an update to a point-release of a dependency of a gem in your Gemfile(5)) can result in radically different gems being needed to satisfy all dependencies.
As a result, you SHOULD check your Gemfile.lock into version control. If you do not, every machine that checks out your repository (including your production server) will resolve all dependencies again, which will result in different versions of third-party code being used if any of the gems in the Gemfile(5) or any of their dependencies have been updated.