CHEF-37441: Add ~/.chef/ruby/VERSION/gems to GEM_PATH for dynamic plugin loading - #192
CHEF-37441: Add ~/.chef/ruby/VERSION/gems to GEM_PATH for dynamic plugin loading#192sanghinitin wants to merge 3 commits into
Conversation
…gin loading
- Update binstub_patch.rb to prepend vendor dir, Gem.user_dir, and
~/.chef/ruby/VERSION/gems to GEM_PATH at runtime so that plugins
installed via 'chef gem install knife-<plugin>' are immediately
available without additional configuration.
Uses RbConfig::CONFIG['ruby_version'] to resolve the correct API
version path at runtime.
- Update habitat/plan.sh wrapper script to include
${HOME}/.gem/ruby/VERSION and ${HOME}/.chef/ruby/VERSION/gems in
GEM_PATH so plugins are discoverable when knife runs in a Habitat
environment on Linux.
- Update habitat/aarch64-darwin/plan.sh wrapper script with same
GEM_PATH additions for macOS ARM64 Habitat builds.
- Update habitat/plan.ps1 to pass --ignore-dependencies to gem install
knife*.gem (avoids appbundler ambiguous specs from duplicate dep
entries) and inject binstub_patch.rb into Windows binstubs after
appbundler generation, matching the Linux/macOS behavior.
Signed-off-by: nitin sanghi <nsanghi@progress.com>
sanghinitin
added
enhancement
…ub_patch.rb Remove leading underscore from knife_vendor, chef_gem_dir, and existing_paths variables — underscore prefix is reserved for intentionally unused variables in Ruby/RuboCop convention. Signed-off-by: nitin sanghi <nsanghi@progress.com>
Signed-off-by: nitin sanghi <nsanghi@progress.com>
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Confirmed: the actual root cause is in chef/appbundler (env_sanitizer clears GEM_HOME/GEM_PATH via ::Gem.clear_paths and never restores user/chef gem paths), which is still actively used in the chef-19 Habitat build pipeline for ohai, chef, knife, chef-cli, and chef-test-kitchen-enterprise. Filed the upstream fix request there. Given the upstream fix will take longer to land and release, resolving this review so the per-repo workaround here isnt blocked -- please just link back to the appbundler upstream issue in the PR description so we remember to remove this workaround once appbundler ships the real fix.
|
Discussed with @sanghinitin and while this isn't ideal, the only solution that comes close is an intermediate package which would still require repo-specific changes |
2 participants
Summary
Ensures gems installed via
chef gem install knife-<plugin>are immediately discoverable by knife at runtime, without requiring any additional configuration.Problem
chef-cli gem installplaces gems under~/.chef/ruby/<RUBY_API_VERSION>/gems(e.g.~/.chef/ruby/3.4.0/gems). This path was not included in theGEM_PATHused by the knife binstubs or the Habitat runtime wrapper, so plugins such asknife-azurewere invisible to knife even afterknife rehash.Changes
binstub_patch.rb— prepend three paths toGEM_PATHat binstub startup:Gem.user_dir→~/.gem/ruby/VERSION(standardgem install)~/.chef/ruby/VERSION/gemsviaRbConfig::CONFIG['ruby_version'](chef-cli gem install)habitat/plan.sh— runtime knife wrapper exports expandedGEM_PATHincluding${HOME}/.gem/ruby/${ruby_gem_version}and${HOME}/.chef/ruby/${ruby_gem_version}/gemshabitat/aarch64-darwin/plan.sh— sameGEM_PATHadditions for macOS ARM64habitat/plan.ps1— two Windows fixes:--ignore-dependenciestogem install knife*.gemto avoid appbundler ambiguous specs errorsbinstub_patch.rbinto generated binstubs afterappbundler.bat, mirroring the Linux/macOSsedapproachEvidence
With this change, knife resolves plugins from that path at launch.
Files Modified
binstub_patch.rbhabitat/plan.shhabitat/aarch64-darwin/plan.shhabitat/plan.ps1