bundler_package_git 1.1.pre.1

data/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/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

data/man/bundle.ronn

@@ -0,0 +1,80 @@
+bundle(1) -- Ruby Dependency Management
+=======================================
+
+## SYNOPSIS
+
+`bundle` COMMAND [--no-color] [--verbose] [ARGS]
+
+## DESCRIPTION
+
+Bundler manages an `application's dependencies` through its entire life
+across many machines systematically and repeatably.
+
+See [the bundler website](http://gembundler.com) for information on getting
+started, and Gemfile(5) for more information on the `Gemfile` format.
+
+## OPTIONS
+
+* `--no-color`:
+  Prints all output without color
+
+* `--verbose`:
+  Prints out additional logging information
+
+## BUNDLE COMMANDS
+
+We divide `bundle` subcommands into primary commands and utilities.
+
+## PRIMARY COMMANDS
+
+* [bundle install(1)][bundle-install]:
+  Install the gems specified by the `Gemfile` or `Gemfile.lock`
+
+* [bundle update(1)][bundle-update]:
+  Update dependencies to their latest versions
+
+* [bundle package(1)][bundle-package]:
+  Package the .gem files required by your application into the
+  `vendor/cache` directory
+
+* [bundle exec(1)][bundle-exec]:
+  Execute a script in the context of the current bundle
+
+* [bundle config(1)][bundle-config]:
+  Specify and read configuration options for bundler
+
+## UTILITIES
+
+* `bundle check(1)`:
+  Determine whether the requirements for your application are installed
+  and available to bundler
+
+* `bundle list(1)`:
+  Show all of the gems in the current bundle
+
+* `bundle show(1)`:
+  Show the source location of a particular gem in the bundle
+
+* `bundle console(1)`:
+  Start an IRB session in the context of the current bundle
+
+* `bundle open(1)`:
+  Open an installed gem in the editor
+
+* `bundle viz(1)`:
+  Generate a visual representation of your dependencies
+
+* `bundle init(1)`:
+  Generate a simple `Gemfile`, placed in the current directory
+
+* `bundle gem(1)`:
+  Create a simple gem, suitable for development with bundler
+
+## OBSOLETE
+
+These commands are obsolete and should no longer be used
+
+* `bundle lock(1)`
+* `bundle unlock(1)`
+* `bundle cache(1)`
+

data/man/gemfile.5.ronn

@@ -0,0 +1,279 @@
+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/rationale.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
+  * `mingw`:
+    Windows 'mingw32' platform (aka RubyInstaller)
+  * `mingw_18`:
+    _mingw_ `AND` version 1.8
+  * `mingw_19`:
+    _mingw_ `AND` version 1.9
+
+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.
+
+## GEMSPEC (#gemspec)
+
+If you wish to use Bundler to help install dependencies for a gem while it is
+being developed, use the `gemspec` method to pull in the dependencies listed in
+the `.gemspec` file.
+
+The `gemspec` method adds any runtime dependencies as gem requirements in the
+default group. It also adds development dependencies as gem requirements in the
+`development` group. Finally, it adds a gem requirement on your project (`:path
+=> '.'`). In conjunction with `Bundler.setup`, this allows you to require project
+files in your test code as you would if the project were installed as a gem; you
+need not manipulate the load path manually or require project files via relative
+paths.
+
+The `gemspec` method supports optional `:path`, `:name`, and `:development_group`
+options, which control where bundler looks for the `.gemspec`, what named
+`.gemspec` it uses (if more than one is present), and which group development
+dependencies are included in.
+
+## 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`.