gemrage 0.0.0

data/vendor/ruby/1.8/gems/bundler-1.0.3/man/bundle-exec.ronn

@@ -0,0 +1,98 @@
+bundle-exec(1) -- Execute a command in the context of the bundle
+================================================================
+
+## SYNOPSIS
+
+`bundle exec` <command>
+
+## DESCRIPTION
+
+This command executes the command, making all gems specified in the
+`Gemfile(5)` available to `require` in Ruby programs.
+
+Essentially, if you would normally have run something like
+`rspec spec/my_spec.rb`, and you want to use the gems specified
+in the `Gemfile(5)` and installed via [bundle install(1)][bundle-install], you
+should run `bundle exec rspec spec/my_spec.rb`.
+
+Note that `bundle exec` does not require that an executable is
+available on your shell's `$PATH`.
+
+## BUNDLE INSTALL --BINSTUBS
+
+If you use the `--binstubs` flag in [bundle install(1)][bundle-install], Bundler will
+automatically create a directory (which defaults to `app_root/bin`)
+containing all of the executables available from gems in the bundle.
+
+After using `--binstubs`, `bin/rspec spec/my_spec.rb` is identical
+to `bundle exec rspec spec/my_spec.rb`.
+
+## ENVIRONMENT MODIFICATIONS
+
+`bundle exec` makes a number of changes to the shell environment,
+then executes the command you specify in full.
+
+* make sure that it's still possible to shell out to `bundle`
+  from inside a command invoked by `bundle exec` (using
+  `$BUNDLE_BIN_PATH`)
+* put the directory containing executables (like `rails`, `rspec`,
+  `rackup`) for your bundle on `$PATH`
+* make sure that if bundler is invoked in the subshell, it uses
+  the same `Gemfile` (by setting `BUNDLE_GEMFILE`)
+* add `-rbundler/setup` to `$RUBYOPT`, which makes sure that
+  Ruby programs invoked in the subshell can see the gems in
+  the bundle
+
+It also modifies Rubygems:
+
+* disallow loading additional gems not in the bundle
+* modify the `gem` method to be a no-op if a gem matching
+  the requirements is in the bundle, and to raise a
+  `Gem::LoadError` if it's not
+* Define `Gem.refresh` to be a no-op, since the source
+  index is always frozen when using bundler, and to
+  prevent gems from the system leaking into the environment
+* Override `Gem.bin_path` to use the gems in the bundle,
+  making system executables work
+* Add all gems in the bundle into Gem.loaded_specs
+
+## RUBYGEMS PLUGINS
+
+At present, the Rubygems plugin system requires all files
+named `rubygems_plugin.rb` on the load path of _any_ installed
+gem when any Ruby code requires `rubygems.rb`. This includes
+executables installed into the system, like `rails`, `rackup`,
+and `rspec`.
+
+Since Rubygems plugins can contain arbitrary Ruby code, they
+commonly end up activating themselves or their dependencies.
+
+For instance, the `gemcutter 0.5` gem depended on `json_pure`.
+If you had that version of gemcutter installed (even if
+you _also_ had a newer version without this problem), Rubygems
+would activate `gemcutter 0.5` and `json_pure <latest>`.
+
+If your Gemfile(5) also contained `json_pure` (or a gem
+with a dependency on `json_pure`), the latest version on
+your system might conflict with the version in your
+Gemfile(5), or the snapshot version in your `Gemfile.lock`.
+
+If this happens, bundler will say:
+
+    You have already activated json_pure 1.4.6 but your Gemfile
+    requires json_pure 1.4.3. Consider using bundle exec.
+
+In this situation, you almost certainly want to remove the
+underlying gem with the problematic gem plugin. In general,
+the authors of these plugins (in this case, the `gemcutter`
+gem) have released newer versions that are more careful in
+their plugins.
+
+You can find a list of all the gems containing gem plugins
+by running
+
+    ruby -rubygems -e "puts Gem.find_files('rubygems_plugin.rb')"
+
+At the very least, you should remove all but the newest
+version of each gem plugin, and also remove all gem plugins
+that you aren't using (`gem uninstall gem_name`).

data/vendor/ruby/1.8/gems/bundler-1.0.3/man/bundle-install.ronn

@@ -0,0 +1,310 @@
+bundle-install(1) -- Install the dependencies specified in your Gemfile
+=======================================================================
+
+## SYNOPSIS
+
+`bundle install` [--local] [--quiet] [--gemfile=GEMFILE] [--system]
+                 [--deployment] [--frozen] [--path]
+                 [--binstubs[=DIRECTORY]] [--without=GROUP1[ GROUP2...]]
+
+## DESCRIPTION
+
+Install the gems specified in your Gemfile(5). If this is the first
+time you run bundle install (and a `Gemfile.lock` does not exist),
+bundler will fetch all remote sources, resolve dependencies and
+install all needed gems.
+
+If a `Gemfile.lock` does exist, and you have not updated your Gemfile(5),
+bundler will fetch all remote sources, but use the dependencies
+specified in the `Gemfile.lock` instead of resolving dependencies.
+
+If a `Gemfile.lock` does exist, and you have updated your Gemfile(5),
+bundler will use the dependencies in the `Gemfile.lock` for all gems
+that you did not update, but will re-resolve the dependencies of
+gems that you did update. You can find more information about this
+update process below under [CONSERVATIVE UPDATING][].
+
+## OPTIONS
+
+* `--gemfile=<gemfile>`:
+  The location of the Gemfile(5) that bundler should use. This defaults
+  to a gemfile in the current working directory. In general, bundler
+  will assume that the location of the Gemfile(5) is also the project
+  root, and will look for the `Gemfile.lock` and `vendor/cache` relative
+  to it.
+
+* `--path=<path>`:
+  The location to install the gems in the bundle to. This defaults
+  to the gem home, which is the location that `gem install` installs
+  gems to. This means that, by default, gems installed without a
+  `--path` setting will show up in `gem list`. This setting is a
+  [remembered option][REMEMBERED OPTIONS].
+
+* `--system`:
+  Installs the gems in the bundle to the system location. This
+  overrides any previous [remembered][REMEMBERED OPTIONS] use of
+  `--path`.
+
+* `--without=<list>`:
+  A space-separated list of groups to skip installing. This is a
+  [remembered option][REMEMBERED OPTIONS].
+
+* `--local`:
+  Do not attempt to connect to `rubygems.org`, instead using just
+  the gems located in `vendor/cache`. Note that if a more
+  appropriate platform-specific gem exists on `rubygems.org`,
+  this will bypass the normal lookup.
+
+* `--deployment`:
+  Switches bundler's defaults into [deployment mode][DEPLOYMENT MODE].
+
+* `--binstubs[=<directory>]`:
+  Create a directory (defaults to `bin`) containing an executable
+  that runs in the context of the bundle. For instance, if the
+  `rails` gem comes with a `rails` executable, this flag will create
+  a `bin/rails` executable that ensures that all dependencies used
+  come from the bundled gems.
+
+## DEPLOYMENT MODE
+
+Bundler's defaults are optimized for development. To switch to
+defaults optimized for deployment, use the `--deployment` flag.
+
+1. A `Gemfile.lock` is required.
+
+   To ensure that the same versions of the gems you developed with
+   and tested with are also used in deployments, a `Gemfile.lock`
+   is required.
+
+   This is mainly to ensure that you remember to check your
+   `Gemfile.lock` into version control.
+
+2. The `Gemfile.lock` must be up to date
+
+   In development, you can modify your Gemfile(5) and re-run
+   `bundle install` to [conservatively update][CONSERVATIVE UPDATING]
+   your `Gemfile.lock` snapshot.
+
+   In deployment, your `Gemfile.lock` should be up-to-date with
+   changes made in your Gemfile(5).
+
+3. Gems are installed to `vendor/bundle` not your default system location
+
+   In development, it's convenient to share the gems used in your
+   application with other applications and other scripts run on
+   the system.
+
+   In deployment, isolation is a more important default. In addition,
+   the user deploying the application may not have permission to install
+   gems to the system, or the web server may not have permission to
+   read them.
+
+   As a result, `bundle install --deployment` installs gems to
+   the `vendor/bundle` directory in the application. This may be
+   overridden using the `--path` option.
+
+## SUDO USAGE
+
+By default, bundler installs gems to the same location as `gem install`.
+
+In some cases, that location may not be writable by your Unix user. In
+that case, bundler will stage everything in a temporary directory,
+then ask you for your `sudo` password in order to copy the gems into
+their system location.
+
+From your perspective, this is identical to installing them gems
+directly into the system.
+
+You should never use `sudo bundle install`. This is because several
+other steps in `bundle install` must be performed as the current user:
+
+* Updating your `Gemfile.lock`
+* Updating your `vendor/cache`, if necessary
+* Checking out private git repositories using your user's SSH keys
+
+Of these three, the first two could theoretically be performed by
+`chown`ing the resulting files to `$SUDO_USER`. The third, however,
+can only be performed by actually invoking the `git` command as
+the current user.
+
+As a result, you should run `bundle install` as the current user,
+and bundler will ask for your password if it is needed to perform
+the final step.
+
+## INSTALLING GROUPS
+
+By default, `bundle install` will install all gems in all groups
+in your Gemfile(5), except those declared for a different platform.
+
+However, you can explicitly tell bundler to skip installing
+certain groups with the `--without` option. This option takes
+a space-separated list of groups.
+
+While the `--without` option will skip _installing_ the gems in the
+specified groups, it will still _download_ those gems and use them to
+resolve the dependencies of every gem in your Gemfile(5).
+
+This is so that installing a different set of groups on another
+ machine (such as a production server) will not change the
+gems and versions that you have already developed and tested against.
+
+`Bundler offers a rock-solid guarantee that the third-party
+code you are running in development and testing is also the
+third-party code you are running in production. You can choose
+to exclude some of that code in different environments, but you
+will never be caught flat-footed by different versions of
+third-party code being used in different environments.`
+
+For a simple illustration, consider the following Gemfile(5):
+
+    source "http://rubygems.org"
+
+    gem "sinatra"
+
+    group :production do
+      gem "rack-perftools-profiler"
+    end
+
+In this case, `sinatra` depends on any version of Rack (`>= 1.0`, while
+`rack-perftools-profiler` depends on 1.x (`~> 1.0`).
+
+When you run `bundle install --without production` in development, we
+look at the dependencies of `rack-perftools-profiler` as well. That way,
+you do not spend all your time developing against Rack 2.0, using new
+APIs unavailable in Rack 1.x, only to have bundler switch to Rack 1.2
+when the `production` group _is_ used.
+
+This should not cause any problems in practice, because we do not
+attempt to `install` the gems in the excluded groups, and only evaluate
+as part of the dependency resolution process.
+
+This also means that you cannot include different versions of the same
+gem in different groups, because doing so would result in different
+sets of dependencies used in development and production. Because of
+the vagaries of the dependency resolution process, this usually
+affects more than just the gems you list in your Gemfile(5), and can
+(surprisingly) radically change the gems you are using.
+
+## REMEMBERED OPTIONS
+
+Some options (marked above in the [OPTIONS][] section) are remembered
+between calls to `bundle install`, and by the Bundler runtime.
+
+For instance, if you run `bundle install --without test`, a subsequent
+call to `bundle install` that does not include a `--without` flag will
+remember your previous choice.
+
+In addition, a call to `Bundler.setup` will not attempt to make the
+gems in those groups available on the Ruby load path, as they were
+not installed.
+
+The settings that are remembered are:
+
+* `--deployment`:
+  At runtime, this remembered setting will also result in Bundler
+  raising an exception if the `Gemfile.lock` is out of date.
+
+* `--path`:
+  Subsequent calls to `bundle install` will install gems to the
+  directory originally passed to `--path`. The Bundler runtime
+  will look for gems in that location. You can revert this
+  option by running `bundle install --system`.
+
+* `--binstubs`:
+  Bundler will update the executables every subsequent call to
+  `bundle install`.
+
+* `--without`:
+  As described above, Bundler will skip the gems specified by
+  `--without` in subsequent calls to `bundle install`. The
+  Bundler runtime will also not try to make the gems in the
+  skipped groups available.
+
+## 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.
+
+## CONSERVATIVE UPDATING
+
+When you make a change to the Gemfile(5) and then run `bundle install`,
+Bundler will update only the gems that you modified.
+
+In other words, if a gem that you `did not modify` worked before
+you called `bundle install`, it will continue to use the exact
+same versions of all dependencies as it used before the update.
+
+Let's take a look at an example. Here's your original Gemfile(5):
+
+    source "http://rubygems.org"
+
+    gem "actionpack", "2.3.8"
+    gem "activemerchant"
+
+In this case, both `actionpack` and `activemerchant` depend on
+`activesupport`. The `actionpack` gem depends on `activesupport 2.3.8`
+and `rack ~> 1.1.0`, while the `activemerchant` gem depends on
+`activesupport >= 2.3.2`, `braintree >= 2.0.0`, and `builder >= 2.0.0`.
+
+When the dependencies are first resolved, Bundler will select
+`activesupport 2.3.8`, which satisfies the requirements of both
+gems in your Gemfile(5).
+
+Next, you modify your Gemfile(5) to:
+
+    source "http://rubygems.org"
+
+    gem "actionpack", "3.0.0.rc"
+    gem "activemerchant"
+
+The `actionpack 3.0.0.rc` gem has a number of new dependencies,
+and updates the `activesupport` dependency to `= 3.0.0.rc` and
+the `rack` dependency to `~> 1.2.1`.
+
+When you run `bundle install`, Bundler notices that you changed
+the `actionpack` gem, but not the `activemerchant` gem. It
+evaluates the gems currently being used to satisfy its requirements:
+
+  * `activesupport 2.3.8`:
+    also used to satisfy a dependency in `activemerchant`,
+    which is not being updated
+  * `rack ~> 1.1.0`:
+    not currently being used to satify another dependency
+
+Because you did not explicitly ask to update `activemerchant`,
+you would not expect it to suddenly stop working after updating
+`actionpack`. However, satisfying the new `activesupport 3.0.0.rc`
+dependency of actionpack requires updating one of its dependencies.
+
+Even though `activemerchant` declares a very loose dependency
+that theoretically matches `activesupport 3.0.0.rc`, bundler treats
+gems in your Gemfile(5) that have not changed as an atomic unit
+together with their dependencies. In this case, the `activemerchant`
+dependency is treated as `activemerchant 1.7.1 + activesupport 2.3.8`,
+so `bundle install` will report that it cannot update `actionpack`.
+
+To explicitly update `actionpack`, including its dependencies
+which other gems in the Gemfile(5) still depend on, run
+`bundle update actionpack` (see `bundle update(1)`).
+
+`Summary`: In general, after making a change to the Gemfile(5) , you
+should first try to run `bundle install`, which will guarantee that no
+other gems in the Gemfile(5) are impacted by the change. If that
+does not work, run [bundle update(1)][bundle-update].

data/vendor/ruby/1.8/gems/bundler-1.0.3/man/bundle-package.ronn

@@ -0,0 +1,59 @@
+bundle-package(1) -- Package your needed `.gem` files into your application
+===========================================================================
+
+## SYNOPSIS
+
+`bundle package`
+
+## DESCRIPTION
+
+Copy all of the `.gem` files needed to run the application into the
+`vendor/cache` directory. In the future, when running [bundle install(1)][bundle-install],
+use the gems in the cache in preference to the ones on `rubygems.org`.
+
+## GIT AND PATH GEMS
+
+In Bundler 1.0, the `bundle package` command only packages `.gem` files,
+not gems specified using the `:git` or `:path` options. This will likely
+change in the future.
+
+## REMOTE FETCHING
+
+By default, if you simply run [bundle install(1)][bundle-install] after running
+[bundle package(1)][bundle-package], bundler will still connect to `rubygems.org`
+to check whether a platform-specific gem exists for any of the gems
+in `vendor/cache`.
+
+For instance, consider this Gemfile(5):
+
+    source "http://rubygems.org"
+
+    gem "nokogiri"
+
+If you run `bundle package` under C Ruby, bundler will retrieve
+the version of `nokogiri` for the `"ruby"` platform. If you deploy
+to JRuby and run `bundle install`, bundler is forced to check to
+see whether a `"java"` platformed `nokogiri` exists.
+
+Even though the `nokogiri` gem for the Ruby platform is
+_technically_ acceptable on JRuby, it actually has a C extension
+that does not run on JRuby. As a result, bundler will, by default,
+still connect to `rubygems.org` to check whether it has a version
+of one of your gems more specific to your platform.
+
+This problem is also not just limited to the `"java"` platform.
+A similar (common) problem can happen when developing on Windows
+and deploying to Linux, or even when developing on OSX and
+deploying to Linux.
+
+If you know for sure that the gems packaged in `vendor/cache`
+are appropriate for the platform you are on, you can run
+`bundle install --local` to skip checking for more appropriate
+gems, and just use the ones in `vendor/cache`.
+
+One way to be sure that you have the right platformed versions
+of all your gems is to run `bundle package` on an identical
+machine and check in the gems. For instance, you can run
+`bundle package` on an identical staging box during your
+staging process, and check in the `vendor/cache` before
+deploying to production.

data/vendor/ruby/1.8/gems/bundler-1.0.3/man/bundle-update.ronn

@@ -0,0 +1,176 @@
+bundle-update(1) -- Update your gems to the latest available versions
+=====================================================================
+
+## SYNOPSIS
+
+`bundle update` <*gems> [--source=NAME]
+
+## DESCRIPTION
+
+Update the gems specified (all gems, if none are specified), ignoring
+the previously installed gems specified in the `Gemfile.lock`. In
+general, you should use [bundle install(1)][bundle-install] to install the same exact
+gems and versions across machines.
+
+You would use `bundle update` to explicitly update the version of a
+gem.
+
+## OPTIONS
+
+* `--source=<name>`:
+  The name of a `:git` or `:path` source used in the Gemfile(5). For
+  instance, with a `:git` source of `http://github.com/rails/rails.git`,
+  you would call `bundle update --source rails`
+
+## UPDATING ALL GEMS
+
+If you run `bundle update` with no parameters, bundler will ignore
+any previously installed gems and resolve all dependencies again
+based on the latest versions of all gems available in the sources.
+
+Consider the following Gemfile(5):
+
+    source "http://rubygems.org"
+
+    gem "rails", "3.0.0.rc"
+    gem "nokogiri"
+
+When you run [bundle install(1)][bundle-install] the first time, bundler will resolve
+all of the dependencies, all the way down, and install what you need:
+
+    Fetching source index for http://rubygems.org/
+    Installing rake (0.8.7)
+    Installing abstract (1.0.0)
+    Installing activesupport (3.0.0.rc)
+    Installing builder (2.1.2)
+    Installing i18n (0.4.1)
+    Installing activemodel (3.0.0.rc)
+    Installing erubis (2.6.6)
+    Installing rack (1.2.1)
+    Installing rack-mount (0.6.9)
+    Installing rack-test (0.5.4)
+    Installing tzinfo (0.3.22)
+    Installing actionpack (3.0.0.rc)
+    Installing mime-types (1.16)
+    Installing polyglot (0.3.1)
+    Installing treetop (1.4.8)
+    Installing mail (2.2.5)
+    Installing actionmailer (3.0.0.rc)
+    Installing arel (0.4.0)
+    Installing activerecord (3.0.0.rc)
+    Installing activeresource (3.0.0.rc)
+    Installing bundler (1.0.0.rc.3)
+    Installing nokogiri (1.4.3.1) with native extensions
+    Installing thor (0.14.0)
+    Installing railties (3.0.0.rc)
+    Installing rails (3.0.0.rc)
+
+    Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.
+
+As you can see, even though you have just two gems in the Gemfile(5), your application
+actually needs 25 different gems in order to run. Bundler remembers the exact versions
+it installed in `Gemfile.lock`. The next time you run [bundle install(1)][bundle-install], bundler skips
+the dependency resolution and installs the same gems as it installed last time.
+
+After checking in the `Gemfile.lock` into version control and cloning it on another
+machine, running [bundle install(1)][bundle-install] will _still_ install the gems that you installed
+last time. You don't need to worry that a new release of `erubis` or `mail` changes
+the gems you use.
+
+However, from time to time, you might want to update the gems you are using to the
+newest versions that still match the gems in your Gemfile(5).
+
+To do this, run `bundle update`, which will ignore the `Gemfile.lock`, and resolve
+all the dependencies again. Keep in mind that this process can result in a significantly
+different set of the 25 gems, based on the requirements of new gems that the gem
+authors released since the last time you ran `bundle update`.
+
+## UPDATING A LIST OF GEMS
+
+Sometimes, you want to update a single gem in the Gemfile(5), and leave the rest of the
+gems that you specified locked to the versions in the `Gemfile.lock`.
+
+For instance, in the scenario above, imagine that `nokogiri` releases version `1.4.4`, and
+you want to update it _without_ updating Rails and all of its dependencies. To do this,
+run `bundle update nokogiri`.
+
+Bundler will update `nokogiri` and any of its dependencies, but leave alone Rails and
+its dependencies.
+
+## OVERLAPPING DEPENDENCIES
+
+Sometimes, multiple gems declared in your Gemfile(5) are satisfied by the same
+second-level dependency. For instance, consider the case of `thin` and
+`rack-perftools-profiler`.
+
+    source "http://rubygems.org"
+
+    gem "thin"
+    gem "rack-perftools-profiler"
+
+The `thin` gem depends on `rack >= 1.0`, while `rack-perftools-profiler` depends
+on `rack ~> 1.0`. If you run bundle install, you get:
+
+    Fetching source index for http://rubygems.org/
+    Installing daemons (1.1.0)
+    Installing eventmachine (0.12.10) with native extensions
+    Installing open4 (1.0.1)
+    Installing perftools.rb (0.4.7) with native extensions
+    Installing rack (1.2.1)
+    Installing rack-perftools_profiler (0.0.2)
+    Installing thin (1.2.7) with native extensions
+    Using bundler (1.0.0.rc.3)
+
+In this case, the two gems have their own set of dependencies, but they share
+`rack` in common. If you run `bundle update thin`, bundler will update `daemons`,
+`eventmachine` and `rack`, which are dependencies of `thin`, but not `open4` or
+`perftools.rb`, which are dependencies of `rack-perftools_profiler`. Note that
+`bundle update thin` will update `rack` even though it's _also_ a dependency of
+`rack-perftools_profiler`.
+
+`In short`, when you update a gem using `bundle update`, bundler will update all
+dependencies of that gem, including those that are also dependencies of another gem.
+
+In this scenario, updating the `thin` version manually in the Gemfile(5),
+and then running [bundle install(1)][bundle-install] will only update `daemons` and `eventmachine`,
+but not `rack`. For more information, see the `CONSERVATIVE UPDATING` section
+of [bundle install(1)][bundle-install].
+
+## RECOMMENDED WORKFLOW
+
+In general, when working with an application managed with bundler, you should
+use the following workflow:
+
+* After you create your Gemfile(5) for the first time, run
+
+    $ bundle install
+
+* Check the resulting `Gemfile.lock` into version control
+
+    $ git add Gemfile.lock
+
+* When checking out this repository on another development machine, run
+
+    $ bundle install
+
+* When checking out this repository on a deployment machine, run
+
+    $ bundle install --deployment
+
+* After changing the Gemfile(5) to reflect a new or update dependency, run
+
+    $ bundle install
+
+* Make sure to check the updated `Gemfile.lock` into version control
+
+    $ git add Gemfile.lock
+
+* If [bundle install(1)][bundle-install] reports a conflict, manually update the specific
+  gems that you changed in the Gemfile(5)
+
+    $ bundle update rails thin
+
+* If you want to update all the gems to the latest possible versions that
+  still match the gems listed in the Gemfile(5), run
+
+    $ bundle update