Say I have two different Rails apps with different gem versions specified in their respective Gemfiles. The first app's Gemfile specifies the latest versions of each gem. The second app's Gemfile specifies older versions of each gem.
If I run bundle install from the root of the first app's directory, and then run bundle install from the root of the second app's directory. Will all the gems on my local machine be reverted to an older state?
The reason I ask is that I want to clone an older rail app's repository from GitHub, run it on my local machine, and play around with it. Thanks!
Related
I'm using Ruby 2.1 and Rails 4.1 on Windows 7. Whenever I run bundle install, all gems are installed in the system path c:/Ruby21/lib/ruby/gems/2.1.0/gems/. I also found the vendor directory in my project.
Coming from PHP composer and node.js npm background, all dependencies should be locally installed in the project vendor folder or node_modules folder. So, my questions are:
Should I install gems in the system path or vendor/bundle?
If all gems or some gems should be installed in the system path, how could it affect the production environment where I may not have shell access?
Should all gems or specific gems be installed in vendor/bundle?
How can I install gems in vendor/bundle?
When you run bundle install, you are using a tool called Bundler.
Bundler takes care of managing your dependencies in a similar way as Composer, but instead of installing everything in the project folder, it installs your gems system-wide, that are shared among all your projects. It keeps track of what project requires which libraries by using the Gemfile in your project folder. So, you should just let Bundler do its thing, it does it very well and is the standard package manager for Rails.
If your host supports Ruby and Rails applications (for example, a PaaS like Heroku), it definitely will support Bundler and all the necessary gems will be installed. If you're talking about a cheap shared hosting without shell access, you won't be able to deploy a Ruby application there anyway because you will need to install the actual Ruby interpreter and other things, which would require shell access.
No.
You shouldn't. There's this article describing how to do it, but it seems to me that
countless times where installing gems globally leaked into other projects on the same machine and led to weird behavior that was annoying to debug
has only ever happened to the author of this article, and I don't think Bundler is at fault. In any case, you should always prepend gem commands with bundle exec (as in bundle exec rspec) and you will never have the mentioned problem. bundle exec makes sure that when you execute a command from a gem, the correct version defined in your Gemfile is called, it is important if you have several version of the same gem installed in your system.
A few years ago when RVM was popular, gemsets achieved a similar goal but got mostly deprecated by rbenv and Bundler.
I am new to rails and am learning about bundler. I understand that bundle install installs all the gems specified in the gemfile but where does it install them to?
Does it install them on my computer permanently so that they can be used by any future project?
If so doesnt this mean my computer gets filled with random gem versions and gem installs that I needed for one example project but may never use again?
By default, bundle install is going to install at the root level so all users on a computer could have access to the gems. So 'yes' it is permanent (at least not tied to your application, you can remove them whenever you want).
Take a look at the man pages for bundler. In here, you'll notice that you can specify to install to a local directory.
Install your dependencies, even gems that are already installed to your system gems, to a location other than your system's gem
repository. In this case, install them to vendor/bundle.
$ bundle install --path vendor/bundle
Further bundle commands or calls to Bundler.setup or Bundler.require
will remember this location.
This will let you install the gems to a location inside your application. So when you delete the example app, you also delete the associated gems.
Also, if you would like to see where a specific gem is installed (say you want to look at its source code), type bundle show <gemname>. This will spit out the path to that gem.
The short answer is 'yes'. The longer answer is that there are some technologies which will reduce or eliminate the problems associated with this effect.
If you install 'RVM':
https://rvm.io/
this will allow you to install multiple versions of Ruby and create individual 'gemsets'. As you enter the directory that contains your project, the ruby version and gemset settings are automatically picked up and the active Ruby version will change. This way you can keep gems separate between projects - and use several Ruby versions at once, including JRuby and other esoteric versions.
To find out where gems are stored, type:
gem environment
into your command line and look for the INSTALLATION_DIRECTORY entry in the response.
I suppose the bundling is going to happen on the heroku servers anyway. What is the purpose of doing it on the local machine?
bundle install
This ensures that all gems specified in Gemfile, together with their dependencies, are available for your application. Running bundle install also generates a Gemfile.lock file, which should be added to your git repository. Gemfile.lock ensures that your deployed versions of gems on Heroku match the version installed locally on your development machine.
If the platforms section of your Gemfile contains Windows entries,
such as mswin or mingw, then the Gemfile.lock file will be ignored.
Heroku also uses that file to resolve and install your application dependencies automatically. All you need to do is to push it.
Refer this link : Click Here
This will update your Gemfile.lock, that heroku uses to install all your gems on your virtual server. The Gemfile.lock contains all information about your gems and their respective versions.
It has two purposes :
It ensures you that, on your machine, you have all the dependencies for your application satisfied;
It updates the Gemfile.lock file. While the Gemfile has the list of your app's gems, the Gemfile.lock has a more.. "detailed" version of it, with the gem's own dependencies, their version constraints... It basically is a snapshot of your project dependencies. This way, your app in production will run with the exact same versions of third-party code as do your code in local.
This ensures that all gems specified in Gemfile, together with their dependencies, are available for your application. Running bundle install also generates a Gemfile.lock file, which should be added to your git repository. Gemfile.lock ensures that your deployed versions of gems on Heroku match the version installed locally on your development machine.
Source: https://devcenter.heroku.com/articles/bundler
I'm using a few gems for interactivity with my database and to provide easy pagination. After deploying my application on my server, it'll automatically execute bundle install to install those gems if they aren't installed yet. This is helpful when I deploy a codebase update including a new gem.
However, there's one gem (will_paginate) I've made a little change to (so that it always shows on what page you are, no matter the total number of pages).
Therefore, I used bundle install --local --path vendor at my local machine (OS X Lion) so that I can easily edit them (at per-app base, instead of system-wide).
Because of dependency problems, I cannot 'just' copy the vendor-folder to my web server. Therefore, I decided to add another rule to my .gitignore-file:
vendor
Because this caused my customized will_paginate-gem not to get uploaded, I executed another command:
git add -f vendor/ruby/1.8/gems/will_paginate
Now, when I push, the only gem in the vendor folder at my web server is will_paginate, which is great.
However, it doesn't get loaded, since it isn't in the bundle path.
I already tried to create a file called .bundle/config and add the following in it:
---
BUNDLE_PATH: vendor
I also tried adding BUNDLE_DISABLE_SHARED_GEMS: "0", but using this, bundle check says it's missing the shared gems.
My question is, how can I add a bundle path vendor, and fallback on the system-wide gem-path.
I find that the the config/environment.rb file looks different in Rails version 3.0.
Also when i add the line "config.gem "authlogic".To environment.rb file
For Rails 3, you no longer edit config/environment.rb. You edit Gemfile, adding
gem 'authlogic'
to it, and then do a
bundle install
more info: http://gembundler.com/rails3.html
There will be a Gemfile.lock, and it lists all the gems and their versions in your project. Bundler's docs:
Whenever your Gemfile.lock changes,
always check it in to version control.
It keeps a history of the exact
versions of all third-party code that
you used to successfully run your
application.
When your co-developers (or you on
another machine) check out your code,
it will come with the exact versions
of all the third-party code your
application used on the machine that
you last developed on (in the
Gemfile.lock). When they run
bundle install, bundler will find the
Gemfile.lock and skip the dependency
resolution step. Instead, it will
install all of the same gems that you
used on the original machine.
Pretty basic step by step tutorial here: http://www.logansbailey.com/2010/10/06/how-to-setup-authlogic-in-rails-3/