appbundler 0.12.3 → 0.13.4

data/spec/fixtures/appbundler-example-app/lib/example_app.rb

@@ -1,3 +1,3 @@
 module ExampleApp
-  IT_WORKS = "yes"
+  IT_WORKS = "yes".freeze
 end

data/spec/spec_helper.rb

@@ -3,7 +3,7 @@ def windows?
 end
 
 RSpec.configure do |c|
-  c.filter_run :focus => true
+  c.filter_run focus: true
   c.run_all_when_everything_filtered = true
   c.filter_run_excluding(not_supported_on_windows: true) if windows?
 end

metadata

@@ -1,57 +1,15 @@
 --- !ruby/object:Gem::Specification
 name: appbundler
 version: !ruby/object:Gem::Version
-  version: 0.12.3
+  version: 0.13.4
 platform: ruby
 authors:
 - Chef Software, Inc.
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2019-04-17 00:00:00.000000000 Z
+date: 2021-06-30 00:00:00.000000000 Z
 dependencies:
-- !ruby/object:Gem::Dependency
-  name: rake
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - ">="
-      - !ruby/object:Gem::Version
-        version: '0'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - ">="
-      - !ruby/object:Gem::Version
-        version: '0'
-- !ruby/object:Gem::Dependency
-  name: rspec
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '3.0'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - "~>"
-      - !ruby/object:Gem::Version
-        version: '3.0'
-- !ruby/object:Gem::Dependency
-  name: pry
-  requirement: !ruby/object:Gem::Requirement
-    requirements:
-    - - ">="
-      - !ruby/object:Gem::Version
-        version: '0'
-  type: :development
-  prerelease: false
-  version_requirements: !ruby/object:Gem::Requirement
-    requirements:
-    - - ">="
-      - !ruby/object:Gem::Version
-        version: '0'
 - !ruby/object:Gem::Dependency
   name: mixlib-shellout
   requirement: !ruby/object:Gem::Requirement
@@ -101,26 +59,9 @@ executables:
 extensions: []
 extra_rdoc_files: []
 files:
-- ".expeditor/config.yml"
-- ".expeditor/update_version.sh"
-- ".github/CODEOWNERS"
-- ".github/ISSUE_TEMPLATE/BUG_TEMPLATE.md"
-- ".github/ISSUE_TEMPLATE/DESIGN_PROPOSAL.md"
-- ".github/ISSUE_TEMPLATE/ENHANCEMENT_REQUEST_TEMPLATE.md"
-- ".github/ISSUE_TEMPLATE/SUPPORT_QUESTION.md"
-- ".github/PULL_REQUEST_TEMPLATE.md"
-- ".github/lock.yml"
-- ".gitignore"
-- ".rspec"
-- ".travis.yml"
-- CHANGELOG.md
-- CODE_OF_CONDUCT.md
-- CONTRIBUTING.md
 - Gemfile
-- LICENSE.txt
-- README.md
+- LICENSE
 - Rakefile
-- VERSION
 - appbundler.gemspec
 - bin/appbundler
 - lib/appbundler.rb
@@ -128,7 +69,6 @@ files:
 - lib/appbundler/cli.rb
 - lib/appbundler/version.rb
 - spec/appbundler/app_spec.rb
-- spec/fixtures/appbundler-example-app/.bundle/config
 - spec/fixtures/appbundler-example-app/Gemfile
 - spec/fixtures/appbundler-example-app/Gemfile.lock.unix
 - spec/fixtures/appbundler-example-app/Gemfile.lock.windows
@@ -150,20 +90,19 @@ required_ruby_version: !ruby/object:Gem::Requirement
   requirements:
   - - ">="
     - !ruby/object:Gem::Version
-      version: '2.3'
+      version: '2.4'
 required_rubygems_version: !ruby/object:Gem::Requirement
   requirements:
   - - ">="
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 3.0.3
+rubygems_version: 3.1.4
 signing_key: 
 specification_version: 4
 summary: Extracts a dependency solution from bundler's Gemfile.lock to speed gem activation
 test_files:
 - spec/appbundler/app_spec.rb
-- spec/fixtures/appbundler-example-app/.bundle/config
 - spec/fixtures/appbundler-example-app/Gemfile
 - spec/fixtures/appbundler-example-app/Gemfile.lock.unix
 - spec/fixtures/appbundler-example-app/Gemfile.lock.windows

data/.expeditor/config.yml

@@ -1,44 +0,0 @@
-# Documentation available at https://expeditor.chef.io/docs/getting-started/
----
-# Slack channel in Chef Software slack to send notifications about build failures, etc
-slack:
-  notify_channel: chef-notify
-
-# This publish is triggered by the `built_in:publish_rubygems` artifact_action.
-rubygems:
-  - appbundler
-
-github:
-  # This deletes the GitHub PR branch after successfully merged into the release branch
-  delete_branch_on_merge: true
-  # The tag format to use (e.g. v1.0.0)
-  version_tag_format: "v{{version}}"
-  # allow bumping the minor release via label
-  minor_bump_labels:
-    - "Expeditor: Bump Version Minor"
-  # allow bumping the major release via label
-  major_bump_labels:
-    - "Expeditor: Bump Version Major"
-
-changelog:
-  rollup_header: Changes not yet released to rubygems.org
-
-# These actions are taken, in order they are specified, anytime a Pull Request is merged.
-merge_actions:
-  - built_in:bump_version:
-      ignore_labels:
-        - "Expeditor: Skip Version Bump"
-        - "Expeditor: Skip All"
-  - bash:.expeditor/update_version.sh:
-      only_if: built_in:bump_version
-  - built_in:update_changelog:
-      ignore_labels:
-        - "Expeditor: Skip Changelog"
-        - "Expeditor: Skip All"
-  - built_in:build_gem:
-      only_if: built_in:bump_version
-
-promote:
-  actions:
-    - built_in:rollover_changelog
-    - built_in:publish_rubygems

data/.expeditor/update_version.sh

@@ -1,12 +0,0 @@
-#!/bin/sh
-#
-# After a PR merge, Chef Expeditor will bump the PATCH version in the VERSION file.
-# It then executes this file to update any other files/components with that new version.
-#
-
-set -evx
-
-sed -i -r "s/^(\s*)VERSION = \".+\"/\1VERSION = \"$(cat VERSION)\"/" lib/appbundler/version.rb
-
-# Once Expeditor finshes executing this script, it will commit the changes and push
-# the commit as a new tag corresponding to the value in the VERSION file.

data/.github/CODEOWNERS

@@ -1,7 +0,0 @@
-# Order is important. The last matching pattern has the most precedence.
-
-*                          @chef/client-maintainers
-.expeditor/**              @chef/jex-team
-README.md                  @chef/docs-team
-RELEASE_NOTES.md           @chef/docs-team
-.github/ISSUE_TEMPLATE/**  @chef/docs-team

data/.github/ISSUE_TEMPLATE/BUG_TEMPLATE.md

@@ -1,29 +0,0 @@
----
-name: � Bug Report
-about: If something isn't working as expected �.
-labels: "Status: Untriaged"
----
-
-# Version:
-
-[Version of the project installed]
-
-# Environment:
-
-[Details about the environment such as the Operating System, cookbook details, etc...]
-
-# Scenario:
-
-[What you are trying to achieve and you can't?]
-
-# Steps to Reproduce:
-
-[If you are filing an issue what are the things we need to do in order to repro your problem?]
-
-# Expected Result:
-
-[What are you expecting to happen as the consequence of above reproduction steps?]
-
-# Actual Result:
-
-[What actually happens after the reproduction steps?]

data/.github/ISSUE_TEMPLATE/DESIGN_PROPOSAL.md

@@ -1,40 +0,0 @@
----
-name: Design Proposal
-about: I have a significant change I would like to propose and discuss before starting
-labels: "Status: Untriaged"
----
-
-### When a Change Needs a Design Proposal
-
-A design proposal should be opened any time a change meets one of the following qualifications:
-
-- Significantly changes the user experience of a project in a way that impacts users.
-- Significantly changes the underlying architecture of the project in a way that impacts other developers.
-- Changes the development or testing process of the project such as a change of CI systems or test frameworks.
-
-### Why We Use This Process
-
-- Allows all interested parties (including any community member) to discuss large impact changes to a project.
-- Serves as a durable paper trail for discussions regarding project architecture.
-- Forces design discussions to occur before PRs are created.
-- Reduces PR refactoring and rejected PRs.
-
----
-
-<!---  Proposal description and rationale.  -->
-
-## Motivation
-
-<!---
-    As a <<user_profile>>,
-    I want to <<functionality>>,
-    so that <<benefit>>.
- -->
-
-## Specification
-
-<!---  A detailed description of the planned implementation. -->
-
-## Downstream Impact
-
-<!---  Which other tools will be impacted by this work?  -->

data/.github/ISSUE_TEMPLATE/ENHANCEMENT_REQUEST_TEMPLATE.md

@@ -1,17 +0,0 @@
----
-name: 🚀 Enhancement Request
-about: I have a suggestion (and may want to implement it 🙂)!
-labels: "Status: Untriaged"
----
-
-### Describe the Enhancement:
-<!---  What you are trying to achieve that you can't? -->
-
-### Describe the Need:
-<!---  What kind of user do you believe would utilize this enhancement, and how many users might want this functionality -->
-
-### Current Alternative
-<!--- Is there a current alternative that you can utilize to workaround the lack of this enhancement -->
-
-### Can We Help You Implement This?:
-<!---  The best way to ensure your enhancement is built is to help implement the enhancement yourself. If you're interested in helping out we'd love to give you a hand to make this possible. Let us know if there's something you need. -->

data/.github/ISSUE_TEMPLATE/SUPPORT_QUESTION.md

@@ -1,12 +0,0 @@
----
-name: 🤗 Support Question
-about: If you have a question 💬, please check out our Slack!
----
-
-We use GitHub issues to track bugs and feature requests. If you need help please post to our Mailing List or join the Chef Community Slack.
-
- * Chef Community Slack at http://community-slack.chef.io/.
- * Chef Mailing List https://discourse.chef.io/
-
-
- Support issues opened here will be closed and redirected to Slack or Discourse.

data/.github/PULL_REQUEST_TEMPLATE.md

@@ -1,15 +0,0 @@
-### Description
-
-[Please describe what this change achieves]
-
-### Issues Resolved
-
-[List any existing issues this PR resolves, or any Discourse or
-StackOverflow discussions that are relevant]
-
-### Check List
-
-- [ ] New functionality includes tests
-- [ ] All tests pass
-- [ ] All commits have been signed-off for the Developer Certificate of Origin. See <https://github.com/chef/chef/blob/master/CONTRIBUTING.md#developer-certification-of-origin-dco>
-- [ ] PR title is a worthy inclusion in the CHANGELOG

data/.github/lock.yml

@@ -1 +0,0 @@
-daysUntilLock: 60

data/.gitignore

@@ -1,19 +0,0 @@
-*.gem
-*.rbc
-/.bundle
-b
-binstubs
-.config
-.yardoc
-Gemfile.lock
-InstalledFiles
-_yardoc
-coverage
-doc/
-lib/bundler/man
-pkg
-rdoc
-spec/reports
-test/tmp
-test/version_tmp
-tmp

data/.rspec

@@ -1,2 +0,0 @@
--c
--f doc

data/.travis.yml

@@ -1,23 +0,0 @@
-language: ruby
-cache: bundler
-dist: xenial
-
-before_install:
-  - gem update --system
-  - gem install bundler || true
-
-rvm:
-  - 2.3.8
-  - 2.4.5
-  - 2.5.5
-  - 2.6.2
-
-branches:
-  only:
-    - master
-
-install:
-  - bundle install --jobs 3 --retry 3
-
-# The integration tests need to see installed gems.
-script: rspec --color --format progress

data/CHANGELOG.md

@@ -1,36 +0,0 @@
-# Appbundler CHANGELOG
-
-This file is used to document the changes between releases of Appbundler
-
-<!-- latest_release 0.12.3 -->
-## [v0.12.3](https://github.com/chef/appbundler/tree/v0.12.3) (2019-04-17)
-
-#### Merged Pull Requests
-- syntax fix [#52](https://github.com/chef/appbundler/pull/52) ([lamont-granquist](https://github.com/lamont-granquist))
-<!-- latest_release -->
-
-<!-- release_rollup since=0.12.2 -->
-### Changes not yet released to rubygems.org
-
-#### Merged Pull Requests
-- syntax fix [#52](https://github.com/chef/appbundler/pull/52) ([lamont-granquist](https://github.com/lamont-granquist)) <!-- 0.12.3 -->
-<!-- release_rollup -->
-
-<!-- latest_stable_release -->
-## [v0.12.2](https://github.com/chef/appbundler/tree/v0.12.2) (2019-04-16)
-
-#### Merged Pull Requests
-- fix syntax for cli options [#51](https://github.com/chef/appbundler/pull/51) ([lamont-granquist](https://github.com/lamont-granquist))
-<!-- latest_stable_release -->
-
-## [v0.12.1](https://github.com/chef/appbundler/tree/v0.12.1) (2019-04-16)
-
-#### Merged Pull Requests
-- add support for extra bin files not in the binstubs [#50](https://github.com/chef/appbundler/pull/50) ([lamont-granquist](https://github.com/lamont-granquist))
-
-## [v0.12.0](https://github.com/chef/appbundler/tree/v0.12.0) (2019-03-18)
-
-#### Merged Pull Requests
-- Update README.md [#47](https://github.com/chef/appbundler/pull/47) ([markan](https://github.com/markan))
-- Require ruby 2.3+ and loosen gem deps [#48](https://github.com/chef/appbundler/pull/48) ([tas50](https://github.com/tas50))
-- Fix the labels to properly bump the gem [#49](https://github.com/chef/appbundler/pull/49) ([tas50](https://github.com/tas50))

data/CODE_OF_CONDUCT.md

@@ -1 +0,0 @@
-Please refer to the Chef Community Code of Conduct at https://www.chef.io/code-of-conduct/

data/CONTRIBUTING.md

@@ -1 +0,0 @@
-Please refer to https://github.com/chef/chef/blob/master/CONTRIBUTING.md

data/README.md

@@ -1,204 +0,0 @@
-# Appbundler
-
-[![Build Status Master](https://travis-ci.org/chef/appbundler.svg?branch=master)](https://travis-ci.org/chef/appbundler) [![Gem Version](https://badge.fury.io/rb/appbundler.svg)](https://badge.fury.io/rb/appbundler)
-
-Appbundler reads a Gemfile.lock and generates code with `gem "some-dep", "= VERSION"` statements to lock the app's dependencies to the versions selected by bundler. This code is used in binstubs for the application so that running (e.g.) `chef-client` on the command line activates the locked dependencies for `chef` before running the command.
-
-This provides the following benefits:
-
-- The application loads faster because rubygems is not resolving dependency constraints at runtime.
-- The application runs with the same dependencies that it would if bundler was used, so we can test applications (that will be installed in an omnibus package) using the default bundler workflow.
-- There's no need to `bundle exec` or patch the bundler runtime into the app.
-- The app can load gems not included in the Gemfile/gemspec. Our use case for this is to load plugins (e.g., for knife and test kitchen).
-- A user can use rvm and still use the application (see below).
-- The application is protected from installation of incompatible dependencies.
-
-## ChefDK Usage
-
-### Primary Design
-
-The 3-argument form of appbundler is used in ChefDK (and should be used elsewhere) to pin multiple apps in the same omnibus install against one master Gemfile.lock.
-
-When used this way appbundler takes three arguments:  the lockdir containing the main Gemfile.lock of the omnibus package, the bindir to install the binstubs to, and
-the gem to appbundle.  In this way all the gems in the omnibus app should be appbundled against the same Gemfile.lock.  The omnibus software definition should bundle install
-this Gemfile.lock prior to appbundling.
-
-This will pin all of the bunstubs against every gem in the referenced Gemfile.lock.  This is equivalent and identical behavior to copying the Gemfile.lock to a
-directory, running `bundle install` and then using `bundle exec` to launch any of the applications.  The only major difference is that the appbundle pins apply only to the
-gems in the gemfile, while `bundle exec` will prevent any other external gems from being able to be loaded into the gemset.
-
-The design goals are brutally simple -- replicating the effects of `bundle exec` against the master Gemfile.lock while allowing the gemset to be open.
-
-### Preventing duplicate gems
-
-One of the features of this approach are that it becomes guaranteed that there will be no duplicate gems.  In order for this to be true, however, all gems must be installed
-only from the master Gemfile.lock (and only one version of a gem may appear in any valid Gemfile.lock).  If the omnibus projects does anything other than a single
-`bundle install` against the master Gemfile.lock to install gems then there likely will be multiple gems installed.  IF the apps are appbundled correctly, however, this
-will still not have any negative effects since all runtime gems are pinned.
-
-Historically this issue has caused problems due to transitive dep issues causing different version of gems to be loaded based on which application was launched which would
-later cause gem conflicts. It also simply caused user confusion.
-
-### Preventing transitive gem issues
-
-Given that ChefDK and most chef applications are open pluggable architectures any arbitrary gems may be loaded lazily at runtime long after the initial application has
-launched.  The classic example of the kind of bug which occurs is external third-party knife-plugins which require gems that are not part of the chef-client/knife
-gemset but which collide with the explict pins on berkshelf.  Since the command line invocation is `knife` the berkshelf gem pins were not applied up front, a lazy
-load of the transitive gem was then executed which activated the latest version which was installed with the knife plugin, then berkshelf was activated which would
-conflict due to a pessimistic pin in the berksehlf gemspec itself.
-
-While this is a complicated set of events it was actually fairly commonly reported:
-
-* https://github.com/chef/chef-dk/issues/1187
-* https://github.com/chef/chef-dk/issues/281
-* https://github.com/berkshelf/berkshelf/issues/1357
-* https://stackoverflow.com/questions/31906153/chef-gemconflicterror-when-running-knife-bootstrap-windows
-* https://github.com/chef/chef-dk/issues/603
-
-The aggressive pinning of all gems in the Gemfile.lock against all apps in the Gemfile.lock have eliminated this complaint entirely.
-
-### Appbundler and bundler coexistance
-
-Since this approach is deliberately inflexible against updating the appbundle pins in order to prevent transitive gem issues, it is instead possible and encouraged to
-use Gemfile and bundler as usual.  If the binstubs detect that they are running from within bundler against an external Gemfile.lock they do not apply any pins
-at all.
-
-* https://github.com/chef/chef-dk/issues/1547
-* https://github.com/chef/appbundler/pull/43
-
-### Encouraged use of bundler by end users
-
-The ability to patch an existing omnibus built package is not well supported.  What it would result in would be the user taking the application Gemfile and
-patching it manually and producing a Gemfile.lock which was solved correctly and then running appubndler against that Gemfile.lock for all the applications in
-the bundle.  The difficult part is obviously the user updating the Gemfile.lock which cannot be automated and ultimately boils down to the process that we
-use internally to solve gem conflict problems and produce the Gemfile.lock as an acutal product by experts.
-
-What is vastly simpler is to create Gemfiles and use bundler to solve specific issues.  In particular the problem of new ChefDK (e.g. ChefDK 3.x) managing
-old chef-client (e.g. 12.x) can be solved via bundler in one specific case.  For knife and test-kitchen the bootstrapped version of chef-client on the target
-host is entirely configurable in those tools.  The only major conflict is in the use of chefspec.  For that use case, users are encouraged to create a much
-more simplified Gemfile with a pinned chef version, berkshelf and chefspec and to `bundle install` and `bundle exec rspec` against the Gemfile.lock.  This
-targeted use of bundler is vastly simpler than attempting to create a Chef-12 "version" of ChefDK 3.x.
-
-The alternative of trying to rebuild appbundled binstubs against an already built Chef-DK is documented here and is terrible idea:
-
-https://github.com/chef/chef-dk/issues/1559#issuecomment-468103827
-
-### BUG: you cannot install git gems using this method
-
-This is simply a bug, although in practice it has turned into a feature.  You should never ship git checked out non production released gems to customers, so should
-always be doing downstream gem releases in order to consume them in omnibus builds.  If this becomes a blocker this bug should just be fixed, but in practice this
-has been a feature that has pushed development down the correct path.
-
-### ChefDK transitive development gem Gemfile.locking madness
-
-A sub-concern and design goal of the three-argument mega-Gemfile.lock appbundling feature is decoupling the purely development gem dependencies of sub-applications
-from each other.  This feature should perhaps have been designed to be decoupled, but since the whole feature was written somewhat "tactically" (aka "code rage")
-to deal with the complexity of the ChefDK builds and this feature is necessary there and came along for the ride.
-
-The ChefDK Gemfile.lock is already hard enough to build as it is, and it does not include any of the development gems for its sub-applications (berkshelf, test-kitchen,
-foodcritic, chefspec, etc, etc, etc).  It is already difficult enough to generate a sane single runtime closure across all the runtime gems.  The development gems used
-to test berkshelf, etc should not be shipped in the omnibus build.  It is also an enormous amount of developer pain to keep the development gems consistent across all
-of those projects, particularly when several of them are or historically were external to the company.
-
-The result of that was a feature of the three argument version of appbundler where it takes the pins from the master ChefDK Gemfile.lock and merges those with the
-gem statements in the Gemfile of the application (e.g. berkshelf) and then creates a combined Gemfile.lock which is written out in the gem directory.  So for ChefDK
-3.8.14 the combined Gemfile.lock which is created for berkshelf is:
-
-```
-/opt/chefdk/embedded/lib/ruby/gems/2.5.0/gems/berkshelf-7.0.7/.appbundler-gemfile20190227-93370-84j06u.lock
-```
-
-That Gemfile.lock is only solved, but not installed at build time when appbundler runs (`bundle lock` not `bundle update/install`) so that the development gems are not
-shipped.  In the testing phase of CI a `bundle install` is run against that so that all the development gems are installed on the testing box, all the pins in the
-master Gemfile.lock will be applied (and those gems are already installed) and all the development gems of the app are installed with the constraints specified in
-the Gemfile of the application.  The testing suite is then run via `bundle exec` against this Gemfile.lock via the `chef test` command.
-
-This ensures that we test the app against every gem pin that we ship, while we allow dev pins between different apps to potentially conflict since those have meaning
-only to the app in question.
-
-Yes, this is complicated, but the alternative(s) would be to either bake every dev gem into the master Gemfile.lock and take the pain of reconciling otherwise meaningless
-gem conficts, or to allow gems to float outside of the Gemfile.lock pins and to be guaranteed of shipping defects sooner or later due to not testing against exactly
-what we ship.
-
-For any consumers outside of ChefDK this Gemfile.lock being created can happily be entirely ignored and it won't hurt you at all.
-
-### The meaning of the --without arg is not what you think
-
-The --without argument to appbundler in the three argument version does not apply to the installed gemset (that is handled entirely by the one `bundle install` which
-should be run against the master Gemfile.lock before appbundler runs) and it does not apply to the appbundled binstubs.
-
-What the --without argument does is affect the rendered transitive gemfile.lock and is used to filter out unnecessary dependencies which conflict with the master
-Gemfile.lock in the omnibus project.  A notable example of this was the github-changelog-generator gem which would pin gems (like `addressable`) to restrictive pins
-and would not solve against the ChefDK master Gemfile.lock.  If github-changelog-generator was in a `:changelog` group it could then be excluded here, and it would not
-conflict during generation of the transitive per-app gemfile.lock.
-
-This argument does not affect the shipping apps in the omnibus build (that should be handled by `--without` arguments to the `bundle install`) or affect the generated
-binstubs.  It is only in the codepath of the transitive lock generation and only affects the groups defined in the sub-application's Gemfile.
-
-The `--without` argument was also added to the 3-argument version of appbundler specifically to handle this issue.  It is silently ignored on the 2-argument version.
-
-## Usage
-
-Install via rubygems: `gem install appbundler` or clone this project and bundle install:
-
-```shell
-git clone https://github.com/chef/appbundler.git
-cd appbundler
-bundle install
-```
-
-Clone whatever project you want to appbundle somewhere else, and bundle install it:
-
-```shell
-mkdir ~/oc
-cd ~/oc
-git clone https://github.com/chef/chef.git
-cd chef
-bundle install
-```
-
-Create a bin directory where your bundled binstubs will live:
-
-```shell
-mkdir ~/appbundle-bin
-# Add to your PATH if you like
-```
-
-Now you can app bundle your project (chef in our example):
-
-```shell
-bin/appbundler ~/oc/chef ~/appbundler-bin
-```
-
-Now you can run all of the app's executables with locked down deps:
-
-```shell
-~/appbundler-bin/chef-client -v
-```
-
-## RVM
-
-The generated binstubs explicitly disable rvm, so the above won't work if you're using rvm. This is intentional, because our use case is for omnibus applications where rvm's environment variables can break the embedded application by making ruby look for gems in rvm's gem repo.
-
-## Contributing
-
-For information on contributing to this project see <https://github.com/chef/chef/blob/master/CONTRIBUTING.md>
-
-## License
-
-- Copyright:: Copyright (c) 2014-2016 Chef Software, Inc.
-- License:: Apache License, Version 2.0
-
-```text
-Licensed under the Apache License, Version 2.0 (the "License");
-you may not use this file except in compliance with the License.
-You may obtain a copy of the License at
-
-    http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
-```