appbundler 0.11.6 → 0.12.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 703fb5ac8b8bcf4d7cd65d46f4bfaa625d4977957d9d5b6791ed4780336062e4
-  data.tar.gz: 8125c71999832e0cb96e60287a56d839fd77ff633520c2c05e2dfd8ea0cc9224
+  metadata.gz: b90fc1cd44078573f169f8eb73c35176a6ed31197017d2674e26fb210de64e7c
+  data.tar.gz: 4bb6f4bdb731359d70371424e5d9c46d4204162a5acd7c7563b712318c246591
 SHA512:
-  metadata.gz: fef53c32469cd9c1bc30b0bfe281eb4c5af74b76cd4da0d91e153e4a443a26f3e741c0dc5ec1ddcf3c32ad64da696a39b39b5db09db696f344f03e0d48f63442
-  data.tar.gz: ac1190460a4d7ff1a0d7760b0ebcaa1923549516477f5e3972f504c36a40124ee5d392dc621d2faa3ffed1ac3bf783d3fd0ff91c70b309ac33c4f9c827f75e59
+  metadata.gz: 43c039d754b3f17c3475068125fa8bb79d45860370c31cfa614a3e778c5c90c0ebae16d3b0d63f14399b8260e9a223814207e649677956d838fb6c85dec7bd2a
+  data.tar.gz: b24147d402b51d1db6e82ad768012c0bfd7f30aa13470252e69ea7d9e404cb651718bccdb3faae371285f720b31e21fd1410727778413a7c16f08faa8558e54e

data/.expeditor/config.yml

@@ -0,0 +1,43 @@
+# 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"
+  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: Exclude From 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

@@ -0,0 +1,12 @@
+#!/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

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

data/.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,21 @@
+# 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/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,14 @@
+### 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>

data/.github/lock.yml

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

data/.travis.yml

@@ -1,14 +1,16 @@
 language: ruby
 cache: bundler
-dist: trusty
+dist: xenial
 
 before_install:
   - gem update --system
-  - gem install bundler
+  - gem install bundler || true
 
 rvm:
-  - 2.4.4
-  - 2.5.1
+  - 2.3.8
+  - 2.4.5
+  - 2.5.5
+  - 2.6.2
 
 branches:
   only:

data/CHANGELOG.md

@@ -0,0 +1,22 @@
+# Appbundler CHANGELOG
+
+This file is used to document the changes between releases of Appbundler
+
+<!-- latest_release 0.12.0 -->
+## [v0.12.0](https://github.com/chef/appbundler/tree/v0.12.0) (2019-03-18)
+
+#### Merged Pull Requests
+- Fix the labels to properly bump the gem [#49](https://github.com/chef/appbundler/pull/49) ([tas50](https://github.com/tas50))
+<!-- latest_release -->
+
+<!-- release_rollup since=0.11.6 -->
+### Changes not yet released to rubygems.org
+
+#### Merged Pull Requests
+- Fix the labels to properly bump the gem [#49](https://github.com/chef/appbundler/pull/49) ([tas50](https://github.com/tas50)) <!-- 0.12.0 -->
+- Require ruby 2.3+ and loosen gem deps [#48](https://github.com/chef/appbundler/pull/48) ([tas50](https://github.com/tas50)) <!-- 0.11.9 -->
+- Update README.md [#47](https://github.com/chef/appbundler/pull/47) ([markan](https://github.com/markan)) <!-- 0.11.8 -->
+<!-- release_rollup -->
+
+<!-- latest_stable_release -->
+<!-- latest_stable_release -->

data/CODE_OF_CONDUCT.md

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

data/README.md

@@ -13,6 +13,130 @@ This provides the following benefits:
 - 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:
@@ -49,7 +173,7 @@ bin/appbundler ~/oc/chef ~/appbundler-bin
 Now you can run all of the app's executables with locked down deps:
 
 ```shell
-~/appbunlder-bin/chef-client -v
+~/appbundler-bin/chef-client -v
 ```
 
 ## RVM

data/VERSION

@@ -0,0 +1 @@
+0.12.0

data/appbundler.gemspec

@@ -6,8 +6,8 @@ require "appbundler/version"
 Gem::Specification.new do |spec|
   spec.name          = "appbundler"
   spec.version       = Appbundler::VERSION
-  spec.authors       = ["Dan DeLeo"]
-  spec.email         = ["dan@chef.io"]
+  spec.authors       = ["Chef Software, Inc."]
+  spec.email         = ["info@chef.io"]
   spec.description   = %q{Extracts a dependency solution from bundler's Gemfile.lock to speed gem activation}
   spec.summary       = spec.description
   spec.homepage      = "https://github.com/chef/appbundler"
@@ -18,12 +18,12 @@ Gem::Specification.new do |spec|
   spec.test_files    = spec.files.grep(%r{^(test|spec|features)/})
   spec.require_paths = ["lib"]
 
-  spec.required_ruby_version = ">= 2.2.0"
+  spec.required_ruby_version = ">= 2.3"
 
   spec.add_development_dependency "rake"
   spec.add_development_dependency "rspec", "~> 3.0"
   spec.add_development_dependency "pry"
 
-  spec.add_dependency "mixlib-shellout", "~> 2.0"
-  spec.add_dependency "mixlib-cli", "~> 1.4"
+  spec.add_dependency "mixlib-shellout", ">= 2.0", "< 4.0"
+  spec.add_dependency "mixlib-cli", ">= 1.4", "< 3.0"
 end

data/lib/appbundler/app.rb

@@ -18,12 +18,30 @@ module Appbundler
     attr_reader :target_bin_dir
     attr_reader :name
 
+    # The bundle_path is always the path to the Gemfile.lock being used, e.g.
+    # /var/cache/omnibus/src/chef/chef-14.10.9/Gemfile.lock or whatever.  If
+    # the name if the gem is not set then we behave like old style 2-arg appbundling
+    # where the gem we are appbundling is in the gemspec in that directory.
+    #
+    # If the name is not nil, then we are doing a multiple-app appbundle where
+    # the Gemfile.lock is the omnibus Gemfile.lock and multiple app gems may be
+    # appbundled against the same Gemfile.lock.
+    #
+    # @param bundle_path [String] the directory path of the Gemfile.lock
+    # @param target_bin_dir [String] the binstub dir, e.g. /opt/chefdk/bin
+    # @param name [String] name of the gem
     def initialize(bundle_path, target_bin_dir, name)
       @bundle_path = bundle_path
       @target_bin_dir = target_bin_dir
       @name = name
     end
 
+    # For the 2-arg version this is the gemfile in the omnibus build directory:
+    # /var/cache/omnibus/src/chef/chef-14.10.9/Gemfile
+    #
+    # For the 3-arg version this is the gemfile in the gems installed directory:
+    # /opt/chefdk/embedded/lib/ruby/gems/2.5.0/gems/berkshelf-7.0.7/Gemfile
+    #
     def gemfile_path
       "#{app_dir}/Gemfile"
     end
@@ -38,6 +56,22 @@ module Appbundler
       req.as_list.map { |r| "\"#{r}\"" }.join(", ")
     end
 
+    # This is only used in the 3-arg version.  The gemfile_path is the path into the actual
+    # installed gem, e.g.: /opt/chefdk/embedded/lib/ruby/gems/2.5.0/gems/berkshelf-7.0.7/Gemfile
+    #
+    # The gemfile_lock is the omnibus gemfile.lock which is in this case:
+    # /var/cache/omnibus/src/chef-dk/chef-dk-3.8.14/Gemfile.lock
+    #
+    # This solves the app gems dependencies against the Gemfile.locks pins so that they do not
+    # conflict (assuming such a solution can be found).
+    #
+    # The "without" argument here applies to the app's Gemfile.  There is no information in
+    # a rendered Gemfile.lock about gem groupings (literally none of that information is ever
+    # rendered by bundler into a Gemfile.lock -- open one up and look for yourself).  So this
+    # without argument then applies only to the transitive gemfile locking creation.  This
+    # codepath does not affect what gems we ship, and does not affect the generation of the
+    # binstubs.
+    #
     def requested_dependencies(without)
       Bundler.settings.temporary(without: without) do
         definition = Bundler::Definition.build(gemfile_path, gemfile_lock, nil)
@@ -52,10 +86,27 @@ module Appbundler
       "github_changelog_generator",
     ]
 
+    # This is a check which is equivalent to asking if we are running 2-arg or 3-arg.  If
+    # we have an "external_lockfile" that means the chef-dk omnibus Gemfile.lock, e.g.:
+    # /var/cache/omnibus/src/chef-dk/chef-dk-3.8.14/Gemfile.lock is being merged with the
+    # Gemfile in e.g. /opt/chefdk/embedded/lib/ruby/gems/2.5.0/gems/berkshelf-7.0.7/Gemfile.
+    # Hence the lockfile is "external" to the gem (it made sense to me at the time).
+    #
+    # If it is not then we're dealing with a single gem install from a single project and not
+    # doing any of the transitive locking and we generate a single set of binstubs from a single
+    # app in a single Gemfile.lock
+    #
     def external_lockfile?
       app_dir != bundle_path
     end
 
+    # This loads the specs from the Gemfile.lock which is called on the command line and is in
+    # the omnibus build space.
+    #
+    # Somewhat confusingly this is also the same as the "external" gemfile.lock, which was originally
+    # called the "local" gemfile.lock here.  In either case it is something like:
+    # /var/cache/omnibus/src/chef-dk/chef-dk-3.8.14/Gemfile.lock
+    #
     def local_gemfile_lock_specs
       gemfile_lock_specs.map do |s|
         #if SHITLIST.include?(s.name)
@@ -68,6 +119,10 @@ module Appbundler
 
     # Copy over any .bundler and Gemfile.lock files to the target gem
     # directory.  This will let us run tests from under that directory.
+    #
+    # This is only on the 2-arg implementations pathway.  This is not used
+    # for the 3-arg version.
+    #
     def copy_bundler_env
       gem_path = installed_spec.gem_dir
       # If we're already using that directory, don't copy (it won't work anyway)
@@ -79,6 +134,12 @@ module Appbundler
       end
     end
 
+    # This is the implementation of the 3-arg version of writing the merged lockfiles,
+    # when called with the 2-arg version it short-circuits, however, to the copy_bundler_env
+    # version above.
+    #
+    # This code does not affect the generated binstubs at all.
+    #
     def write_merged_lockfiles(without: [])
       unless external_lockfile?
         copy_bundler_env
@@ -296,6 +357,12 @@ E
       Gem::Specification.find_by_name(app_spec.name, app_spec.version)
     end
 
+    # In the 2-arg version of appbundler this loads the gemspec from the omnibus source
+    # build directory (e.g. /var/cache/omnibus/src/chef/chef-14.10.9/chef.gemspec)
+    #
+    # For the 3-arg version of appbundler this loads the gemspec from the installed path
+    # of the gem (e.g. /opt/chefdk/embedded/lib/ruby/gems/2.5.0/specifications/berkshelf-7.0.7.gemspec)
+    #
     def app_spec
       if name.nil?
         Gem::Specification.load("#{bundle_path}/#{File.basename(@bundle_path)}.gemspec")
@@ -304,6 +371,12 @@ E
       end
     end
 
+    # In the 2-arg version of appbundler this will be the the appdir of the gemspec in the
+    # omnibus build directory (e.g. /var/cache/omnibus/src/chef/chef-14.10.9)
+    #
+    # In the 3-arg version of appbundler this will be the installed gems path
+    # (e.g. /opt/chefdk/embedded/lib/ruby/gems/2.5.0/gems/berkshelf-7.0.7/)
+    #
     def app_dir
       if name.nil?
         File.dirname(app_spec.loaded_from)

data/lib/appbundler/version.rb

@@ -1,3 +1,3 @@
 module Appbundler
-  VERSION = "0.11.6"
+  VERSION = "0.12.0"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: appbundler
 version: !ruby/object:Gem::Version
-  version: 0.11.6
+  version: 0.12.0
 platform: ruby
 authors:
-- Dan DeLeo
+- Chef Software, Inc.
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2018-05-14 00:00:00.000000000 Z
+date: 2019-03-18 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: rake
@@ -56,46 +56,67 @@ dependencies:
   name: mixlib-shellout
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
         version: '2.0'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '4.0'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
         version: '2.0'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '4.0'
 - !ruby/object:Gem::Dependency
   name: mixlib-cli
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
         version: '1.4'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '3.0'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
         version: '1.4'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '3.0'
 description: Extracts a dependency solution from bundler's Gemfile.lock to speed gem
   activation
 email:
-- dan@chef.io
+- info@chef.io
 executables:
 - appbundler
 extensions: []
 extra_rdoc_files: []
 files:
+- ".expeditor/config.yml"
+- ".expeditor/update_version.sh"
+- ".github/CODEOWNERS"
+- ".github/ISSUE_TEMPLATE.md"
+- ".github/PULL_REQUEST_TEMPLATE.md"
+- ".github/lock.yml"
 - ".gitignore"
 - ".rspec"
 - ".travis.yml"
+- CHANGELOG.md
+- CODE_OF_CONDUCT.md
 - Gemfile
 - LICENSE.txt
 - README.md
 - Rakefile
+- VERSION
 - appbundler.gemspec
 - bin/appbundler
 - lib/appbundler.rb
@@ -125,15 +146,14 @@ required_ruby_version: !ruby/object:Gem::Requirement
   requirements:
   - - ">="
     - !ruby/object:Gem::Version
-      version: 2.2.0
+      version: '2.3'
 required_rubygems_version: !ruby/object:Gem::Requirement
   requirements:
   - - ">="
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubyforge_project: 
-rubygems_version: 2.7.6
+rubygems_version: 3.0.1
 signing_key: 
 specification_version: 4
 summary: Extracts a dependency solution from bundler's Gemfile.lock to speed gem activation