Merge pull request rubygems#182 from bundler/seg-1-11

Add v1.11

Rakefile

@@ -9,7 +9,7 @@ task :update_vendor => ["vendor/bundler"] do
   Dir.chdir("vendor/bundler") { sh "git fetch" }
 end
 
-VERSIONS = %w(v1.0 v1.1 v1.2 v1.3 v1.5 v1.6 v1.7 v1.8 v1.9 v1.10).freeze
+VERSIONS = %w(v1.0 v1.1 v1.2 v1.3 v1.5 v1.6 v1.7 v1.8 v1.9 v1.10 v1.11).freeze
 desc "Print the Bundler versions the site documents"
 task :versions do
   puts VERSIONS.join(' ')

source/shared/_whats_new.haml

@@ -1,6 +1,7 @@
 %h1 What's New in each Release
 .buttons
-  = link_to 'v1.10', '/v1.10/whats_new.html'
+  = link_to 'v1.11', '/v1.11/whats_new.html'
+  = link_to 'v1.10', '/v1.10/whats_new.html#version110'
   = link_to 'v1.9', '/v1.9/whats_new.html#version19'
   = link_to 'v1.8', '/v1.8/whats_new.html#version18'
   = link_to 'v1.7', '/v1.7/whats_new.html#version17'

source/v1.11/bundle_binstubs.haml

@@ -0,0 +1,18 @@
+%h2 bundle binstubs
+
+.contents
+  .bullet
+    .description
+      Installs the binstubs of the listed gem
+    :code
+      $ bundle binstubs [GEM] [--force] [--path=PATH]
+    .notes
+      %p
+        Options:
+      %p
+        <code>--force</code>: Overwrite existing binstubs if they exist.
+      %p
+        <code>--path</code>: Binstub destination directory (default bin)
+    .description
+      Generate binstubs for executables in [GEM]. Binstubs are put into bin,
+      or the --binstubs directory if one has been set.

source/v1.11/bundle_check.haml

@@ -0,0 +1,23 @@
+%h2 bundle check
+
+.contents
+  .bullet
+    .description
+      Checks if the dependencies listed in Gemfile are satisfied by currently installed gems
+    :code
+      $ bundle check [--dry-run] [--gemfile=FILE] [--path=PATH]
+    .notes
+      %p
+        Options:
+      %p
+        <code>--dry-run</code>: Locks the Gemfile.
+      %p
+        <code>--gemfile</code>: Use the specified gemfile instead of Gemfile.
+      %p
+        <code>--path</code>: Specify a different path than the system default
+        ($BUNDLE_PATH or $GEM_HOME). Bundler will remember this value for future
+        installs on this machine.
+    .description
+      Check searches the local machine for each of the gems requested in the Gemfile. If
+      all gems are found, Bundler prints a success message and exits with a status of 0.
+      If not, the first missing gem is listed and Bundler exits status 1.

source/v1.11/bundle_clean.haml

@@ -0,0 +1,16 @@
+%h2 bundle clean
+
+.contents
+  .bullet
+    .description
+      Cleans up unused gems in your bundler directory
+    :code
+      $ bundle clean [--dry-run] [--force]
+    .notes
+      %p
+        Options:
+      %p
+        <code>--dry-run</code>: Only print out changes, do not actually clean
+        gems
+      %p
+        <code>--force</code>: Forces clean even if --path is set

source/v1.11/bundle_config.haml

@@ -0,0 +1,275 @@
+%h2 bundle config
+
+.contents
+  .bullet
+    .description
+      Retrieve or set a configuration value
+    :code
+      $ bundle config [NAME [VALUE]] [--local] [--global] [--delete]
+    .notes
+      %p
+        Options:
+      %p
+        <code>--local</code>: Get/set local configuration
+      %p
+        <code>--global</code>: Get/set global configuration
+      %p
+        <code>--delete</code>: Delete <code>NAME</code> value
+    .description
+      %p
+        Retrieves or sets a configuration value. If only parameter is provided,
+        retrieve the value. If two parameters are provided, replace the existing
+        value with the newly provided one.
+      %p
+        By default, setting a configuration value sets it for all projects on
+        the machine.
+      %p
+        If a global setting is superceded by local configuration, this command
+        will show the current value, as well as any superceded values and where
+        they were specified.
+
+  .bullet#config
+    .description
+      Get your bundle configuration.
+    .how
+      :code
+        $ bundle config
+      .notes
+        Executing <code>bundle config</code> with no parameters will print a
+        list of all bundler configuration for the current bundle, and where
+        that configuration was set.
+
+  .bullet#get
+    .description
+      Get your bundle configuration for <code>NAME</code> variable.
+    .how
+      :code
+        $ bundle config NAME
+      .notes
+        Will print the value of that configuration setting for
+        <code>NAME</code>, and where it was set. Will print both local and
+        global configuration.
+
+  .bullet#set
+    .description
+      Set your bundle configuration for <code>NAME</code> variable to
+      <code>VALUE</code>.
+    .how
+      :code
+        $ bundle config NAME VALUE
+      .notes
+        Will set <code>NAME</code> to <code>VALUE</code> for all bundles
+        executed as the current user (i.e. global setting). The configuration
+        will be stored in  <code>~/.bundle/config</code>. If <code>NAME</code>
+        already is set, <code>NAME</code> will be overridden and user will be
+        warned.
+
+  .bullet#global
+    .description
+      Set your bundle global/user configuration for <code>NAME</code> variable
+      to <code>VALUE</code>.
+    .how
+      :code
+        $ bundle config --global NAME VALUE
+      .notes
+        Works the same as the command above.
+
+  .bullet#local
+    .description
+      Set your bundle local configuration for <code>NAME</code> variable to
+      <code>VALUE</code>.
+    .how
+      :code
+        $ bundle config --local NAME VALUE
+      .notes
+        Works the same as the two command above but for the local application.
+        The configuration will be stored in <code>app/.bundle/config</code>.
+
+  .bullet#delete
+    .description
+      Delete the configuration for <code>NAME</code> in both local and global sources.
+    .how
+      :code
+        $ bundle config --delete NAME
+      .notes
+        Will delete the configuration for <code>NAME</code> variable in both local and global sources. Not compatible with --global or --local flag.
+
+%h2 Build options
+.contents
+  .bullet#build_options
+    .description
+      %p
+        You can use <code>bundle config</code> to give bundler the flags to
+        pass to the gem installer every time bundler tries to install a
+        particular gem.
+
+      %p
+        A very common example, the <code>mysql</code> gem, requires Snow
+        Leopard users to pass configuration flags to <code>gem install</code>
+        to specify where to find the <code>mysql_config</code> executable.
+
+      .how
+        :code
+          $ gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config
+
+      %p
+        Since the specific location of that executable can change from machine
+        to machine, you can specify these flags on a per-machine basis.
+
+      .how
+        :code
+          $ bundle config build.mysql --with-mysql-config=/usr/local/mysql/bin/mysql_config
+      %p
+        After running this command, every time bundler needs to install the
+        <code>mysql</code> gem, it will pass along the flags you specified.
+
+
+%h2 Configuration keys
+.contents
+  .bullet#configuration_keys
+    .description
+      %p
+        Configuration keys in bundler have two forms: the canonical form and
+        the environment variable form.
+
+      %p
+        For instance, passing the <code>--without</code> flag to
+        <code>bundle install</code> prevents Bundler from installing
+        certain groups specified in the <code>Gemfile</code>. Bundler persists
+        this value in <code>app/.bundle/config</code> so that calls to
+        <code>Bundler.setup</code> do not try to find gems from the
+        <code>Gemfile</code> that you didn't install. Additionally, subsequent
+        calls to <code>bundle install</code> remember this setting and
+        skip those groups.
+
+      %p
+        The canonical form of this configuration is <code>"without"</code>. To
+        convert the canonical form to the environment variable form, capitalize
+        it, and prepend <code>BUNDLE_</code>. The environment variable form of
+        <code>"without"</code> is <code>BUNDLE_WITHOUT</code>.
+
+%h2 List of available keys
+.contents
+  .bullet#available_keys
+    .description
+      %p
+        The following is a list of all configuration keys and their purpose.
+        You can learn more about their operation in
+        <code>bundle install</code>.
+      %ul
+        %li
+          <code>auto_install</code> (<code>1</code>): Setting auto_install config
+          to 1 or any other truthy value will enable automatic installing of gems
+          instead of raising an error. This behavior applies to the following
+          commands: <code>show</code>, <code>binstubs</code>,
+          <code>outdated</code>, <code>exec</code>, <code>open</code>,
+          <code>console</code>, <code>license</code>, <code>clean</code>.
+        %li
+          <code>path</code> (<code>BUNDLE_PATH</code>): The location on disk
+          to install gems. Defaults to <code>$GEM_HOME</code> in development
+          and <code>vendor/bundle</code> when <code>--deployment</code> is used.
+        %li
+          <code>frozen</code> (<code>BUNDLE_FROZEN</code>): Disallow changes to
+          the <code>Gemfile</code>. Defaults to <code>true</code> when
+          <code>--deployment</code> is used.
+        %li
+          <code>without</code> (<code>BUNDLE_WITHOUT</code>): A
+          <code>:</code>-separated list of groups whose gems bundler should not
+          installer
+        %li
+          <code>bin</code> (<code>BUNDLE_BIN</code>): Install executables from
+          gems in the bundle to the specified directory. Defaults to
+          <code>false</code>.
+        %li
+          <code>gemfile</code> (<code>BUNDLE_GEMFILE</code>): The name of the
+          file that bundler should use as the <code>Gemfile</code>. This location
+          of this file also sets the root of the project, which is used to
+          resolve relative paths in the <code>Gemfile</code>, among other things.
+          By default, bundler will search up from the current working directory
+          until it finds a <code>Gemfile</code>.
+        %li
+          <code>ssl_ca_cert</code> (<code>BUNDLE_SSL_CA_CERT</code>): 
+          Path to a designated CA certificate file or folder containing multiple
+          certificates for trusted CAs in PEM format.
+        %li
+          <code>ssl_client_cert</code> (<code>BUNDLE_SSL_CLIENT_CERT</code>):
+          Path to a designated file containing a X.509 client certificate
+          and key in PEM format.
+        %li
+          <code>cache_path</code> (<code>BUNDLE_CACHE_PATH</code>): The directory
+          that bundler will place cached gems in when running <code>bundle
+          package</code> and that bundler will look in when installing with the
+          <code>--deployment</code> option.
+        %li
+          <code>disable_multisource</code> (<code>BUNDLE_DISABLE_MULTISOURCE</code>):
+          When set, Gemfiles containing multiple sources will produce an error
+          instead of a warning. Use <code>bundle config --delete
+          disable_multisource</code> to unset.
+
+      %p
+        In general, you should set these settings per-application by using the
+        applicable flag to the <code>bundle install</code> or <code>bundle
+        package</code> command.
+
+      %p
+        You can set them globally either via environment variables or
+        <code>bundle config</code>, whichever is preferable for your setup. If
+        you use both, environment variables will take preference over global
+        settings.
+
+%h2 Local git repositories
+.contents
+  .bullet#local_git_repos
+    .description
+      %p
+        Bundler also allows you to work against a git repository locally
+        instead of using the remote version. This can be achieved by setting
+        up a local override:
+
+      :code
+        $ bundle config local.GEM_NAME /path/to/local/git/repository
+
+      %p
+        For example, in order to use a local Rack repository, a developer
+        could call:
+
+      :code
+        $ bundle config local.rack ~/Work/git/rack
+
+      %p
+        Now instead of checking out the remote git repository, the local
+        override will be used. Similar to a path source, every time the local
+        git repository change, changes will be automatically picked up by
+        Bundler. This means a commit in the local git repo will update the
+        revision in the <code>Gemfile.lock</code> to the local git repo
+        revision. This requires the same attention as git submodules. Before
+        pushing to the remote, you need to ensure the local override was
+        pushed, otherwise you may point to a commit that only exists in your
+        local machine.
+
+      %p
+        Bundler does many checks to ensure a developer won't work with
+        invalid references. Particularly, we force a developer to specify a
+        branch in the <code>Gemfile</code> in order to use this feature. If the
+        branch specified in the `Gemfile` and the current branch in the local
+        git repository do not match, Bundler will abort. This ensures that a
+        developer is always working against the correct branches, and prevents
+        accidental locking to a different branch.
+
+      %p
+        Finally, Bundler also ensures that the current revision in the
+        <code>Gemfile.lock</code> exists in the local git repository. By doing
+        this, Bundler forces you to fetch the latest changes in the remotes.
+
+%h2 Gem Source Mirrors
+.contents
+  .bullet#gem-source-mirrors
+    .description
+      %p
+        If your environment contains a local mirror of the rubygems.org server,
+        use the <code>mirror.URL</code> configuration option to supply the URL
+        of the mirror. At that point, Bundler will download gems and gemspecs
+        from that mirror instead of the source listed in the Gemfile.
+
+      :code
+        $ bundle config mirror.https://rubygems.org https://localgems.lan

source/v1.11/bundle_console.haml

@@ -0,0 +1,15 @@
+%h2 bundle console
+
+.contents
+  .bullet
+    .description
+      Start an interactive Ruby console session in the context of the current bundle
+    :code
+      $ bundle console [GROUP]
+
+    .description
+      <code>bundle console</code> uses irb by default. Alternatives like Pry and Ripl can be used with bundle console by adjusting the <code>console</code> Bundler setting. Also make sure that <code>pry</code> or <code>ripl</code> is in your Gemfile.
+    :code
+      $ bundle config console pry
+      $ bundle console
+      [1] pry(main)>

source/v1.11/bundle_exec.haml

@@ -0,0 +1,26 @@
+%h2 bundle exec
+
+.contents
+  .bullet
+    .description
+      Run the command in context of the bundle
+    :code
+      $ bundle exec [--keep-file-descriptors] <command>
+    .notes
+      %p
+        Options:
+      %p
+        <code>--keep-file-descriptors</code>: For Ruby versions less than 2.0,
+        keeps non-standard file descriptors on Kernel#exec
+
+    .description
+      This command executes the command, making all gems specified in the
+      <code>Gemfile(5)</code> available to <code>require</code> in Ruby programs.
+
+      Essentially, if you would normally have run something like
+      <code>rspec spec/my_spec.rb</code>, and you want to use the gems specified
+      in the <code>Gemfile</code> and installed via <code>bundle install</code>, you
+      should run <code>bundle exec rspec spec/my_spec.rb</code>.
+
+      Note that <code>bundle exec</code> does not require that an executable is
+      available on your shell's <code>$PATH</code>.