bpm 0.1.0

data/spec/fixtures/src/bundler-1.1.pre/ISSUES.md

@@ -0,0 +1,47 @@
+# Bundler Issues
+
+## Troubleshooting
+
+Instructions for common Bundler use-cases can be found on the [Bundler documentation site](http://gembundler.com/v1.0/). Detailed information about each Bundler command, including help with common problems, can be found in the [Bundler man pages](http://gembundler.com/man/bundle.1.html).
+
+After reading the documentation, try these troubleshooting steps:
+
+    # remove user-specific gems and git repos
+    rm -rf ~/.bundle/ ~/.gem/
+
+    # remove system-wide git repos and git checkouts
+    rm -rf $GEM_HOME/bundler/ $GEM_HOME/cache/bundler/
+
+    # remove project-specific settings and git repos
+    rm -rf .bundle/
+
+    # remove project-specific cached .gem files
+    rm -rf vendor/cache/
+
+    # remove the saved resolve of the Gemfile
+    rm -rf Gemfile.lock
+
+    # try to install one more time
+    bundle install
+
+## Reporting unresolved problems
+
+If you are still having problems, please report issues to the [Bundler issue tracker](http://github.com/carlhuda/bundler/issues/).
+
+Instructions that allow the Bundler team to reproduce your issue are vitally important. When you report a bug, please create a gist of the following information and include a link in your ticket:
+
+  - What version of bundler you are using
+  - What version of Ruby you are using
+  - Whether you are using RVM, and if so what version
+  - Your Gemfile
+  - Your Gemfile.lock
+  - If you are on 0.9, whether you have locked or not
+  - If you are on 1.0, the result of `bundle config`
+  - The command you ran to generate exception(s)
+  - The exception backtrace(s)
+
+If you are using Rails 2.3, please also include:
+
+  - Your boot.rb file
+  - Your preinitializer.rb file
+  - Your environment.rb file

data/spec/fixtures/src/bundler-1.1.pre/LICENSE

@@ -0,0 +1,21 @@
+Portions copyright (c) 2010 Andre Arko
+Portions copyright (c) 2009 Engine Yard
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/spec/fixtures/src/bundler-1.1.pre/README.md

@@ -0,0 +1,29 @@
+# Bundler: a gem to bundle gems
+
+Bundler is a tool that manages gem dependencies for your ruby application. It
+takes a gem manifest file and is able to fetch, download, and install the gems
+and all child dependencies specified in this manifest. It can manage any update
+to the gem manifest file and update the bundle's gems accordingly. It also lets
+you run any ruby code in context of the bundle's gem environment.
+
+### Installation and usage
+
+See [gembundler.com](http://gembundler.com) for up-to-date installation and usage instructions.
+
+### Troubleshooting
+
+For help with common problems, see [ISSUES](http://github.com/carlhuda/bundler/blob/master/ISSUES.md).
+
+### Development
+
+To see what has changed in recent versions of bundler, see the [CHANGELOG](http://github.com/carlhuda/bundler/blob/master/CHANGELOG.md).
+
+The `master` branch contains our current progress towards version 1.1. Because of that, please submit bugfix pull requests against the `1-0-stable` branch.
+
+### Upgrading from Bundler 0.8 to 0.9 and above
+
+See [UPGRADING](http://github.com/carlhuda/bundler/blob/master/UPGRADING.md).
+
+### Other questions
+
+Feel free to chat with the Bundler core team (and many other users) on IRC in the  [#bundler](irc://irc.freenode.net/bundler) channel on Freenode, or via email on the [Bundler mailing list](http://groups.google.com/group/ruby-bundler).

data/spec/fixtures/src/bundler-1.1.pre/UPGRADING.md

@@ -0,0 +1,103 @@
+## Bundler 0.9 to 1.0 and above
+
+Upgrading from Bundler 0.9 to 1.0 is relatively painless. The
+Gemfile API is the same, so your old Gemfiles should continue
+to work.
+
+The "env" file that 0.9 created at `.bundle/environment.rb` has been
+removed. As a side effect of this, Passenger will only find your
+bundled gems if you install with `bundle install --deployment`.
+Alternatively, you can tell Passenger where you gems are installed,
+[something like this](http://bit.ly/passenger-gem-home).
+
+The `bundle lock` command is no longer needed, as the
+Gemfile.lock file is now automatically generated by `bundle install`.
+If you have not yet done so, add your Gemfile.lock to source control
+and check it in.
+
+Running `bundle install` no longer updates the versions of your gems.
+If you need to update just one gem, run `bundle update GEMNAME`. To
+update all gems to the newest versions possible, run `bundle update`.
+
+Bundler now supports multiple platforms, using a block syntax to
+declare platform-specific gems:
+
+    platform :jruby do
+      gem "jruby-maven-plugins"
+    end
+
+Deploying using Bundler is even easier than it was before, as Bundler
+now includes a Capistrano recipe. Simply add this line to the top of
+your deploy.rb file to run Bundler automatically as part of deploying:
+
+    require 'bundler/capistrano'
+
+For more details on deploying using bundler, see the documentation
+for the bundler cap task, and the [documentation on deploying](http://gembundler.com/v1.0/deploying.html).
+
+
+## Bundler 0.8 to 0.9 and above
+
+Upgrading to Bundler 0.9 from Bundler 0.8 requires upgrading several
+API calls in your Gemfile, and some workarounds if you are using Rails 2.3.
+
+### Gemfile Removals
+
+Bundler 0.9 removes the following Bundler 0.8 Gemfile APIs:
+
+1. `disable_system_gems`: This is now the default (and only) option
+   for bundler. Bundler uses the system gems you have specified
+   in the Gemfile, and only the system gems you have specified
+   (and their dependencies)
+2. `disable_rubygems`: This is no longer supported. We are looking
+   into ways to get the fastest performance out of each supported
+   scenario, and we will make speed the default where possible.
+3. `clear_sources`: Bundler now defaults to an empty source
+   list. If you want to include Rubygems, you can add the source
+   via source "http://gemcutter.org". If you use bundle init, this
+   source will be automatically added for you in the generated
+   Gemfile
+4. `bundle_path`: You can specify this setting when installing
+   via `bundle install /path/to/bundle`. Bundler will remember
+   where you installed the dependencies to on a particular
+   machine for future installs, loads, setups, etc.
+5. `bin_path`: Bundler no longer generates binaries in the root
+   of your app. You should use `bundle exec` to execute binaries
+   in the current context.
+
+### Gemfile Changes
+
+Bundler 0.9 changes the following Bundler 0.8 Gemfile APIs:
+
+1. Bundler 0.8 supported :only and :except as APIs for describing
+   groups of gems. Bundler 0.9 supports a single `group` method,
+   which you can use to group gems together. See the above "Group"
+   section for more information.
+
+   This means that `gem "foo", :only => :production` becomes
+   `gem "foo", :group => :production`, and
+   `only :production { gem "foo" }` becomes
+   `group :production { gem "foo" }`
+
+   The short version is: group your gems together logically, and
+   use the available commands to make use of the groups you've
+   created.
+
+2. `:require_as` becomes `:require`
+
+3. `:vendored_at` is fully removed; you should use `:path`
+
+### API Changes
+
+1. `Bundler.require_env(:environment)` becomes
+   `Bundler.require(:multiple, :groups)`. You must
+   now specify the default group (the default group is the
+   group made up of the gems not assigned to any group)
+   explicitly. So `Bundler.require_env(:test)` becomes
+   `Bundler.require(:default, :test)`
+
+2. `require 'vendor/gems/environment'`: In unlocked
+   mode, where using system gems, this becomes
+   `Bundler.setup(:multiple, :groups)`. If you don't
+   specify any groups, this puts all groups on the load
+   path. In locked, mode, it becomes `require '.bundle/environment'`

data/spec/fixtures/src/bundler-1.1.pre/bin/bundle

@@ -0,0 +1,20 @@
+#!/usr/bin/env spade
+
+// Non-functioning code just for testing
+
+# Check if an older version of bundler is installed
+require('bundler')
+
+try {
+  Bundler.CLI.start();
+} catch(e) {
+  if (e instanceof Bundler.BundlerError) {
+    Bundler.ui.error(e.message);
+    Bundler.ui.debug(e.backtrace.join("\n"));
+    exit(e.statusCode);
+  } else if (e instanceof Interrupt) {
+    Bundler.ui.error("\nQuitting...");
+    Bundler.ui.debug e.backtrace.join("\n");
+    exit(1);
+  }
+}

data/spec/fixtures/src/bundler-1.1.pre/lib/bundler.js

@@ -0,0 +1,23 @@
+/*globals Bundler ENV WINDOWS */
+
+require('rbconfig');
+require('fileutils');
+require('pathname');
+require('yaml');
+require('bundler/rubygems_ext');
+require('bundler/version');
+
+Bundler = {
+  ORIGINAL_ENV: ENV,
+
+  Definition:          require.autoload('bundler/definition'),
+  Dependency:          require.autoload('bundler/dependency'),
+  Dsl:                 require.autoload('bundler/dsl'),
+  UI:                  require.autoload('bundler/ui'),
+
+  WINDOWS: ENV["host_os"].match(/!(msdos|mswin|djgpp|mingw)/),
+  FREEBSD: ENV["host_os"].match(/bsd/),
+  NULL:    WINDOWS ? "NUL" : "/dev/null"
+
+};
+

data/spec/fixtures/src/bundler-1.1.pre/lib/bundler/definition.js

@@ -0,0 +1,14 @@
+require("digest/sha1");
+
+Bundler.Definition = {
+
+  build: function(gemfile, lockfile, unlock) {
+    unluck = unlock || {};
+    gemfile = Pathname.new(gemfile).expandPath();
+    if (!gemfile.file()) {
+      throw new GemfileNotFound(gemfile+' not found');
+    }
+    Dsl.evaluate(gemfile, lockfile, unlock);
+  }
+};
+

data/spec/fixtures/src/bundler-1.1.pre/lib/bundler/dependency.js

@@ -0,0 +1,15 @@
+require('rubygems/dependency');
+require('bundler/shared_helpers');
+require('bundler/rubygems_ext');
+
+Bundler.Dependency = {
+  autorequire: false,
+  groups: [],
+  platforms: [],
+  
+  PLATFORM_MAP = {
+    'ruby': 'RUBY',
+    'ruby_18': 'RUBY'
+  }
+} ;
+

data/spec/fixtures/src/bundler-1.1.pre/lib/bundler/dsl.js

@@ -0,0 +1,9 @@
+require('bundler/dependency');
+
+Bundler.Dsl = {
+  evaluate: function(gemfile, lockfile, unlock) {
+    var builder = new Bundler.Dsl();
+    builder.instanceEval(Bundler.readFile(gemfile.toString()), gemfile.toString(), 1);
+    builder.toDefinition(lockfile, unlock);
+  }
+};

data/spec/fixtures/src/bundler-1.1.pre/lib/bundler/ui.js

@@ -0,0 +1,6 @@
+
+Bundler.UI = {
+  warn: function(message) {},
+  debug: function(message) {},
+  error: function(message) {}  
+};

data/spec/fixtures/src/bundler-1.1.pre/man/bundle-config.ronn

@@ -0,0 +1,90 @@
+bundle-config(1) -- Set bundler configuration options
+=====================================================
+
+## SYNOPSIS
+
+`bundle config` [<name> [<value>]]
+
+## DESCRIPTION
+
+This command allows you to interact with bundler's configuration system.
+Bundler retrieves its configuration from the local application (`app/.bundle/config`),
+environment variables, and the user's home directory (`~/.bundle/config`),
+in that order of priority.
+
+Executing `bundle config` with no parameters will print a list of all
+bundler configuration for the current bundle, and where that configuration
+was set.
+
+Executing `bundle config <name>` will print the value of that configuration
+setting, and where it was set.
+
+Executing `bundle config <name> <value>` will set that configuration to the
+value specified for all bundles executed as the current user. The configuration
+will be stored in `~/.bundle/config`.
+
+## BUILD OPTIONS
+
+You can use `bundle config` to give bundler the flags to pass to the gem
+installer every time bundler tries to install a particular gem.
+
+A very common example, the `mysql` gem, requires Snow Leopard users to
+pass configuration flags to `gem install` to specify where to find the
+`mysql_config` executable.
+
+    gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config
+
+Since the specific location of that executable can change from machine
+to machine, you can specify these flags on a per-machine basis.
+
+    bundle config build.mysql --with-mysql-config=/usr/local/mysql/bin/mysql_config
+
+After running this command, every time bundler needs to install the
+`mysql` gem, it will pass along the flags you specified.
+
+## CONFIGURATION KEYS
+
+Configuration keys in bundler have two forms: the canonical form and the
+environment variable form.
+
+For instance, passing the `--without` flag to [bundle install(1)][bundle-install]
+prevents Bundler from installing certain groups specified in the Gemfile(5). Bundler
+persists this value in `app/.bundle/config` so that calls to `Bundler.setup`
+do not try to find gems from the `Gemfile` that you didn't install. Additionally,
+subsequent calls to [bundle install(1)][bundle-install] remember this setting and skip those
+groups.
+
+The canonical form of this configuration is `"without"`. To convert the canonical
+form to the environment variable form, capitalize it, and prepend `BUNDLE_`. The
+environment variable form of `"without"` is `BUNDLE_WITHOUT`.
+
+## LIST OF AVAILABLE KEYS
+
+The following is a list of all configuration keys and their purpose. You can
+learn more about their operation in [bundle install(1)][bundle-install].
+
+* `path` (`BUNDLE_PATH`):
+  The location on disk to install gems. Defaults to `$GEM_HOME` in development
+  and `vendor/bundler` when `--deployment` is used
+* `frozen` (`BUNDLE_FROZEN`):
+  Disallow changes to the `Gemfile`. Defaults to `true` when `--deployment`
+  is used.
+* `without` (`BUNDLE_WITHOUT`):
+  A `:`-separated list of groups whose gems bundler should not install
+* `bin` (`BUNDLE_BIN`):
+  Install executables from gems in the bundle to the specified directory.
+  Defaults to `false`.
+* `gemfile` (`BUNDLE_GEMFILE`):
+  The name of the file that bundler should use as the `Gemfile`. This location
+  of this file also sets the root of the project, which is used to resolve
+  relative paths in the `Gemfile`, among other things. By default, bundler
+  will search up from the current working directory until it finds a
+  `Gemfile`.
+
+In general, you should set these settings per-application by using the applicable
+flag to the [bundle install(1)][bundle-install] command.
+
+You can set them globally either via environment variables or `bundle config`,
+whichever is preferable for your setup. If you use both, environment variables
+will take preference over global settings.
+

data/spec/fixtures/src/bundler-1.1.pre/man/bundle-exec.ronn

@@ -0,0 +1,111 @@
+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
+
+### Shelling out
+
+When shelling out (using the `system` or backticks methods,
+for example), Bundler's environment changes will propogate to
+the subshell environment. If you desire to shell out without
+Bundler's environment changes, simply employ the `with_clean_env`
+method. It will restore all environment variables to what they
+were before Bundler was activated. For example:
+
+    Bundler.with_clean_env do
+      `brew install wget`
+    end
+
+## 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`).