Bundler and Rails 3.1 on AppCloud »

Created at: 24.06.2011 02:04, source: Engine Yard Blog, tagged: Technology Tips & Tricks appcloud bundler rails 3.1

Specifying the correct gem dependency in your Ruby on Rails application has always been very important. Luckily, Bundler has made our lives much easier by taking care of many of the headaches for us. There have been many changes to the codebase with Rails 3.1. With Rails 3.1 on the horizon, it is increasingly important to know which versions of gems are needed for an application depending on the Rails version. Here are some things to think about when preparing for deployment.

Common Errors with Gem Versions

Below are some common errors that we have received lately on the Engine Yard AppCloud platform.

Gem::SilentUI (NameError)

Lately, we have received an elevated amount of tickets when people try to deploy with the error: "uninitialized constant Gem::SilentUI (NameError)". The problem is that this error does not really tell people what is wrong.

Different Bundler Versions

Most of the time, this issue can be resolved by checking the system Bundler version on your instance against the Bundler version on your development machine. If the system version is 1.0.0 or below and your machine version is 1.0.15, then the easiest thing to do is add gem 'bundler', '1.0.15' to your Gemfile. Then just run bundle update bundler from the command line and re-deploy your application.

no such file to load -- active_record/connection_adapters/mysql2_adapter

This is another error that does not really explain what the problem is. In Rails 3.1, the ActiveRecord MySQL2 Adapter is included by default and therefore is not provided in the mysql2 gem in versions greater than 0.3.

Rails 3.1 and Higher

For versions of Rails 3.1 and up, you just want to add gem 'mysql2', '~> 0.3' to your Gemfile.

Below Rails 3.1

If you are using a version of Rails lower than 3.1, you need to tell bundler the version of mysql2 to use and it needs to be lower that 0.3. Adding gem 'mysql2', '~> 0.2.7' to your Gemfile should take care of this.

What does this mean for my application?

It is increasingly important to require the correct version of your gems in your Gemfile. You should also use bundle exec <command> from your application so you only use the gem versions specified for your environment. A better option is to use binstubs which are automatically installed on AppCloud instances. Just run bin/rspec or bin/<executable> instead of just rspec or <executable> and your commands will be run against the application environment.

More Information


more »

Bundler Usage — Installing Gems »

Created at: 18.03.2011 17:52, source: Ruby Rockers, tagged: Uncategorized bundler rails ruby Ruby on Rails



Every time you change your Gemfile then you might adding/removing any dependancies in your application.

Just bundle install will install gems for you.

The output may look like 

$ bundle install
Fetching git://github.com/rails/rails.git
Fetching source index for http://rubygems.org/
Using rake (0.8.7)
Installing abstract (1.0.0)
Your bundle is complete! Use `bundle show [gemname]` to see where a
bundled gem is installed.

You can specify groups for special environments 

$ bundle install --without development test

$ bundle install --without test

You can specify installation directory for your gems.
This will install all the gems into tmp/bundle folder

$ bundle install --path tmp/bundle

You can check your applications bundler config. 

$ bundle config 

Settings are listed in order of priority. The top value will be used.

disable_shared_gems
  Set for your local app (/Users/arunagw/errorapp/.bundle/config): "1"

path
  Set for your local app (/Users/arunagw/errorapp/.bundle/config): "tmp/bundle"

For more details about bundler you can checkout http://gembundler.com/
And also http://railscasts.com/episodes/201-bundler


more »

Bundler Usage — Manage Gemfile »

Created at: 17.03.2011 08:34, source: Ruby Rockers, tagged: Technology bundler gemfile rails



In the previous post we posted about basic Bundler usage. Here i am posting about some advance way of managing Gemfile.

Bundler requires a Gemfile. If you are creating a Rails application which is above to version 3, the Gemfile automatic gets created.

Gemfile contains all your dependent gems.

gem "rails", "~> 3.0.5"

gem "mysql2"

The above Gemfile explains that we need Rails 3.0.5 and Mysql2 gems for our application.

Gemfile can be manage in different ways.

We can group things together which is only used in specific environment.

group :test do
  gem "faker
end
group :development, :test do
  gem 'ruby-debug'
end

We can specify the gem version as a second argument in gem. If there is no version then it will fetch the latest one.

Some time gem name is different and the library needs to be loaded may be different. Then we need to specify specifically the lib name.

gem 'sqlite3-ruby', :require => 'sqlite3'

Loading gem from a git repository directly

If our library or gem is hosted somewhere else then we can add more source at the top of Gemfile. But if we want to fetch Gem from a git repository then we need to something like below. But that library must contain a .gemspec file to consider as a Gem.

gem 'nokogiri', :git => 'git://github.com/tenderlove/nokogiri.git'

We can also specify a branch/tag/ref of git repository.

gem 'nokogiri', :git => 'git://github.com/tenderlove/nokogiri.git',
                                   :branch => 'stable-2'
gem 'nokogiri', :git => 'git://github.com/tenderlove/nokogiri.git',
                                   :tag => 'tag-2'
gem 'nokogiri', :git => 'git://github.com/tenderlove/nokogiri.git',
                                   :ref => '23456'

We can load gems from our local path also.

gem 'nokogiri', :path => '~/code/nokogiri'


more »

Deployment Best Practices with Engine Yard and Bundler 1.0 »

Created at: 22.09.2010 13:28, source: Engine Yard Blog, tagged: Uncategorized bundler

Bundler 1.0 was recently released and it is better than ever. The dependency resolution is now smarter and more flexible, a ton of bugs were fixed, and it has generally gotten much easier to use. We have been using Bundler at Engine Yard since the first version that was actually part of Merb. Things have changed a lot since then, but the basics are actually still pretty much the same: tell the tool what your dependencies are, it will figure out what set of gems satisfy those dependencies and make them available to your application. Now that Bundler is at 1.0 and is stable and solid, I highly recommend that everyone use it to deploy their applications. There are a few best practices that will make using Bundler to deploy work seamlessly.

Check in your Gemfile.lock

This was always a best practice when using Bundler in earlier versions. If you don't check in the lockfile, the only thing Bundler can do when deploying, is resolve all of the gems. If a new gem was released since you last tested, you could end up deploying to production with a different set of dependencies than you tested. In Bundler 1.0, when using the --deployment flag, it is required that you check in your lockfile. It will not let you deploy without one. At Engine Yard we use --deployment whenever you are using Bundler 1.0.

Your bundle should be shared across deploys, but not across applications

When you deploy your code, it would be better if Bundler did not have to rebuild every gem in your application's dependencies. You can do this by having Bundler install the gems in a place that is shared between deploys. At Engine Yard we automatically tell Bundler to put your gems in /data/app-name/shared/bundled_gems. This way you still get the benefit of having your application gems separate from your system gems, but you also don't have to rebuild every gem on every deploy.

Use groups to limit what is installed on production

Most applications have a set of dependencies that they may only want during development of their application. This could be test frameworks like rspec or cucumber, or a gem used for debugging locally like ruby-debug. When deploying with Engine Yard, Bundler does not automatically install or make available anything in the development or test groups. Your Gemfile could look something like this: 
gem "rails"

group :test do
  gem "rspec", :require => "spec"
end

group :development do
  gem "ruby-debug"
end
Then when you deploy to production, you will get the rails gem and all of its dependencies, but ruby-debug and rspec will not be installed.

Package your gems before deployment

This recommendation is a bit more of a gray area. Bundler includes the bundle package command that will put the packed .gem files into your application so when you deploy, everything your app needs is already there. This makes your deployments less failure prone in the case that the gem servers are down. In reality gemcutter is not down often, and hopefully if you follow recommendation #2, most deploys should not even need to fetch any gems (except when the dependencies of your application change). This also means that there are a few more megabytes of data in your git repo. I still think it is a good idea to be resilient to those kinds of failures, but there is a trade off. Bundler 1.0 is an amazing tool that completely changes the way you think about dependencies and deployment. I feel much more comfortable knowing that any deploy that I do using Bundler is not going to randomly fail because I forgot to install a gem on my production server. With these few tips, deploys should be even more foolproof when it comes to your applications' dependencies.


more »

Double Shot #652 »

Created at: 19.02.2010 13:56, source: A Fresh Cup, tagged: Double Shot bundler css git hoptoad jquery nested_attributes query_trace rails

Remember kids, sleep is for the weak and sensible.


more »

bgurl
ипотпал
аквичоп


Tag cloud

Categories

Links

Blogs: 43
Posts: 2355