Move the man pages to the bundler repository and write a build task to convert them into roff and txt format.

1 files changed, 254 insertions, 0 deletions

diff --git a/man/gemfile.5.ronn b/man/gemfile.5.ronn
new file mode 100644
index 00000000..a7152eeb
--- /dev/null
+++ b/man/gemfile.5.ronn
@@ -0,0 +1,254 @@
+Gemfile(5) -- A format for describing gem dependencies for Ruby programs
+========================================================================
+
+## SYNOPSIS
+
+A `Gemfile` describes the gem dependencies required to execute associated
+Ruby code.
+
+Place the `Gemfile` in the root of the directory containing the associated
+code. For instance, in a Rails application, place the `Gemfile` in the same
+directory as the `Rakefile`.
+
+## SYNTAX
+
+A `Gemfile` is evaluated as Ruby code, in a context which makes available
+a number of methods used to describe the gem requirements.
+
+## SOURCES (#source)
+
+At the top of the `Gemfile`, add one line for each `Rubygems` source that
+might contain the gems listed in the `Gemfile`.
+
+    source "http://rubygems.org"
+    source "http://gems.github.com"
+
+Each of these _source_s `MUST` be a valid Rubygems repository.
+
+## GEMS (#gem)
+
+Specify gem requirements using the `gem` method, with the following arguments.
+All parameters are `OPTIONAL` unless otherwise specified.
+
+### NAME (required)
+
+For each gem requirement, list a single _gem_ line.
+
+    gem "nokogiri"
+
+### VERSION
+
+Each _gem_ `MAY` have one or more version specifiers.
+
+    gem "nokogiri", ">= 1.4.2"
+    gem "RedCloth", ">= 4.1.0", "< 4.2.0"
+
+### REQUIRE AS (:require)
+
+Each _gem_ `MAY` specify its main file, which should be used when autorequiring
+(`Bundler.require`).
+
+    gem "sqlite3-ruby", :require => "sqlite3"
+
+This defaults to the name of the gem itself. For instance, these are identical:
+
+    gem "nokogiri"
+    gem "nokogiri", :require => "nokogiri"
+
+### GROUPS (:group or :groups)
+
+Each _gem_ `MAY` specify membership in one or more groups. Any _gem_ that does
+not specify membership in any group is placed in the `default` group.
+
+    gem "rspec", :group => :test
+    gem "wirble", :groups => [:development, :test]
+
+The Bundler runtime allows its two main methods, `Bundler.setup` and
+`Bundler.require`, to limit their impact to particular groups.
+
+    # setup adds gems to Ruby's load path
+    Bundler.setup                    # defaults to all groups
+    require "bundler/setup"          # same as Bundler.setup
+    Bundler.setup(:default)          # only set up the _default_ group
+    Bundler.setup(:test)             # only set up the _test_ group (but `not` _default_)
+    Bundler.setup(:default, :test)   # set up the _default_ and _test_ groups, but no others
+
+    # require requires all of the gems in the specified groups
+    Bundler.require                  # defaults to just the _default_ group
+    Bundler.require(:default)        # identical
+    Bundler.require(:default, :test) # requires the _default_ and _test_ groups
+    Bundler.require(:test)           # requires just the _test_ group
+
+The Bundler CLI allows you to specify a list of groups whose gems `bundle install` should
+not install with the `--without` option. To specify multiple groups to ignore, specify a
+list of groups separated by spaces.
+
+    bundle install --without test
+    bundle install --without development test
+
+After running `bundle install --without test`, bundler will remember that you excluded
+the test group in the last installation. The next time you run `bundle install`, 
+without any `--without option`, bundler will recall it.
+
+Also, calling `Bundler.setup` with no parameters, or calling `require "bundler/setup"`
+will setup all groups except for the ones you excluded via `--without` (since they
+are obviously not available).
+
+Note that on `bundle install`, bundler downloads and evaluates all gems, in order to
+create a single canonical list of all of the required gems and their dependencies.
+This means that you cannot list different versions of the same gems in different
+groups. For more details, see [Understanding Bundler](http://gembundler.com/v1.0/understanding.html).
+
+### PLATFORMS (:platforms)
+
+If a gem should only be used in a particular platform or set of platforms, you can 
+specify them. Platforms are essentially identical to groups, except that you do not
+need to use the `--without` install-time flag to exclude groups of gems for other
+platforms.
+
+There are a number of `Gemfile` platforms:
+
+  * `ruby`:
+    C Ruby (MRI) or Rubinius, but `NOT` Windows
+  * `ruby_18`:
+    _ruby_ `AND` version 1.8
+  * `ruby_19`:
+    _ruby_ `AND` version 1.9
+  * `mri`:
+    Same as _ruby_, but not Rubinius
+  * `mri_18`:
+    _mri_ `AND` version 1.8
+  * `mri_19`:
+    _mri_ `AND` version 1.9
+  * `jruby`:
+    JRuby
+  * `mswin`:
+    Windows
+
+As with groups, you can specify one or more platforms:
+
+    gem "weakling",   :platforms => :jruby
+    gem "ruby-debug", :platforms => :mri_18
+    gem "nokogiri",   :platforms => [:mri_18, :jruby]
+
+All operations involving groups (`bundle install`, `Bundler.setup`,
+`Bundler.require`) behave exactly the same as if any groups not
+matching the current platform were explicitly excluded.
+
+### GIT (:git)
+
+If necessary, you can specify that a gem is located at a particular
+git repository. The repository can be public (`http://github.com/rails/rails.git`)
+or private (`git@github.com:rails/rails.git`). If the repository is private,
+the user that you use to run `bundle install` `MUST` have the appropriate
+keys available in their `$HOME/.ssh`.
+
+Git repositories are specified using the `:git` parameter. The `group`,
+`platforms`, and `require` options are available and behave exactly the same
+as they would for a normal gem.
+
+    gem "rails", :git => "git://github.com/rails/rails.git"
+
+A git repository `SHOULD` have at least one file, at the root of the
+directory containing the gem, with the extension `.gemspec`. This file
+`MUST` contain a valid gem specification, as expected by the `gem build`
+command. It `MUST NOT` have any dependencies, other than on the files in
+the git repository itself and any built-in functionality of Ruby or Rubygems.
+
+If a git repository does not have a `.gemspec`, bundler will attempt to
+create one, but it will not contain any dependencies, executables, or
+C extension compilation instructions. As a result, it may fail to properly
+integrate into your application.
+
+If a git repository does have a `.gemspec` for the gem you attached it
+to, a version specifier, if provided, means that the git repository is
+only valid if the `.gemspec` specifies a version matching the version
+specifier. If not, bundler will print a warning.
+
+    gem "rails", "2.3.8", :git => "git://github.com/rails/rails.git"
+    # bundle install will fail, because the .gemspec in the rails
+    # repository's master branch specifies version 3.0.0
+
+If a git repository does `not` have a `.gemspec` for the gem you attached
+it to, a version specifier `MUST` be provided. Bundler will use this
+version in the simple `.gemspec` it creates.
+
+Git repositories support a number of additional options.
+
+  * `branch`, `tag`, and `ref`:
+    You `MUST` only specify at most one of these options. The default
+    is `:branch => "master"`
+  * `submodules`:
+    Specify `:submodules => true` to cause bundler to expand any
+    submodules included in the git repository
+
+If a git repository contains multiple `.gemspecs`, each `.gemspec`
+represents a gem located at the same place in the file system as
+the `.gemspec`.
+
+    |~rails                   [git root]
+    | |-rails.gemspec         [rails gem located here]
+    |~actionpack
+    | |-actionpack.gemspec    [actionpack gem located here]
+    |~activesupport
+    | |-activesupport.gemspec [activesupport gem located here]
+    ...
+
+To install a gem located in a git repository, bundler changes to
+the directory containing the gemspec, runs `gem build name.gemspec`
+and then installs the resulting gem. The `gem build` command,
+which comes standard with Rubygems, evaluates the `.gemspec` in
+the context of the directory in which it is located.
+
+### PATH (:path)
+
+You can specify that a gem is located in a particular location
+on the file system. Relative paths are resolved relative to the
+directory containing the `Gemfile`.
+
+Similar to the semantics of the `:git` option, the `:path`
+option requires that the directory in question either contains
+a `.gemspec` for the gem, or that you specify an explicit
+version that bundler should use.
+
+Unlike `:git`, bundler does not compile C extensions for
+gems specified as paths.
+
+    gem "rails", :path => "vendor/rails"
+
+## BLOCK FORM OF GIT, PATH, GROUP and PLATFORMS
+
+The `:git`, `:path`, `:group`, and `:platforms` options may be
+applied to a group of gems by using block form.
+
+    git "git://github.com/rails/rails.git" do
+      gem "activesupport"
+      gem "actionpack"
+    end
+
+    platforms :ruby do
+      gem "ruby-debug"
+      gem "sqlite3-ruby"
+    end
+
+    group :development do
+      gem "wirble"
+      gem "faker"
+    end
+
+In the case of the `git` block form, the `:ref`, `:branch`, `:tag`,
+and `:submodules` options may be passed to the `git` method, and
+all gems in the block will inherit those options.
+
+## SOURCE PRIORITY
+
+When attempting to locate a gem to satisfy a gem requirement,
+bundler uses the following priority order:
+
+  1. The source explicitly attached to the gem (using `:path` or `:git`)
+  2. For implicit gems (dependencies of explicit gems), any git or path
+     repository otherwise declared. This results in bundler prioritizing the
+     ActiveSupport gem from the Rails git repository over ones from
+     `rubygems.org`
+  3. The sources specified via `source`, in the order in which they were
+     declared in the `Gemfile`.