Gemfile Options

By -
You can do any of the following in the Gemfile:
  • gem "name", "version": version may be a strict version or a version requirement like >= 1.0.6. The version is optional.

  • gem "name", "version", :require_as => "file": the require_as allows you to specify which file should be required when the require_env is called. By default, it is the gem’s name

  • gem "name", "version", :only => :testing: The environment name can be anything. It is used later in your require_env call. You may specify either :only, or :except constraints

  • gem "name", "version", :git => "git://github.com/wycats/thor": Specify a git repository to be used to satisfy the dependency. You must use a hard dependency (“1.0.6″) rather than a soft dependency (“>= 1.0.6″). If a .gemspec is found in the repository, it is used for further dependency lookup. If the repository has multiple .gemspecs, each directory will a .gemspec will be considered a gem.

  • gem "name", "version", :git => "git://github.com/wycats/thor", :branch => "experimental": Further specify a branch, tag, or ref to use. All of :branch, :tag, and :ref are valid options

  • gem "name", "version", :vendored_at => "vendor/nokogiri": In the next version of bundler, this option will be changing to :path. This specifies that the dependency can be found in the local file system, rather than remotely. It is resolved relative to the location of the Gemfile

  • clear_sources: Empties the list of gem sources to search inside of.

  • source "http://gems.github.com": Adds a gem source to the list of available gem sources.

  • bundle_path "vendor/my_gems": Changes the default location of bundled gems from vendor/gems

  • bin_path "my_executables": Changes the default location of the installed executables

  • disable_system_gems: Without this command, both bundled gems and system gems will be used. You can therefore have things like ruby-debug in your system and use it. However, it also means that you may be using something in development mode that is installed on your system but not available in production. For this reason, it is best to disable_system_gems

  • disable_rubygems: This completely disables rubygems, reducing startup times considerably. However, it often doesn’t work if libraries you are using depend on features of Rubygems. In this mode, the bundler shims the features of Rubygems that we know people are using, but it’s possible that someone is using a feature we’re unaware of. You are free to try disable_rubygems first, then remove it if it doesn’t work. Note that Rails 2.3 cannot be made to work in this mode

  • only :environment { gem "rails" }: You can use only or except in block mode to specify a number of gems at once

Comments

Post a Comment

Popular posts from this blog

Inserting and Moving elements inside Ruby Array

By -
Here's is an array with 5 elements 2.1.2 :001 > arr = ["a", "b", "c", "d", "e"] => ["a", "b", "c", "d", "e"] Lets look at few different cases Insert a new element at starting position Using unshift 2.1.2 :002 > arr.unshift("f") => ["f", "a", "b", "c", "d", "e"] Using insert 2.1.2 :005 > arr.insert(0, "f") => ["f", "a", "b", "c", "d", "e"] In the above example 0 is the position(index) Move existing element from one position to another The element in this case is "e" Using uniq to show only unique elements 2.1.2 :009 > arr.insert(0, "e").uniq => ["e", "a", "b", "c", "d"] With uniq we are only showing unique records but the element is listed
Read more

Difference between Validations, Callbacks and Observers

By -
Validations allow you to ensure that only valid data is stored in your database. Example: validates_presence_of :user_name, :password validates_numericality_of :value We can write custom validation also as def validate   errors.add(:price, “should be a positive value”) if price.nil?|| price < 0.01 end Callbacks and observers allow you to trigger logic before or after an alteration of an object’s state. Callbacks are methods that get called at certain moments of an object’s life cycle. With callbacks it’s possible to write code that will run whenever an Active Record object is created, saved, updated, deleted, validated, or loaded from the database. Callbacks are hooks into the life cycle of an Active Record object that allow you to trigger logic before or after an alteration of the object state. This can be used to make sure that associated and dependent objects are deleted when destroy is called (by overwriting before_destroy) or to massage attribu
Read more