Could appbundler allow for a custom GEM_PATH instead of nil ?

[Tensibai]

Describe the Enhancement:

Allow appbundler to define a custom GEM_PATH and GEM_HOME instead of nil.

Describe the Need:

Habitat packages have their environment made by the supervisor, when installing a hab package with -b it creates a symlink in /bin. You can expect that binary to behave as if within a supervisor, but that's actually not the case as appbundler reset GEM_PATH to nil here

ENV["GEM_HOME"] = ENV["GEM_PATH"] = nil unless ENV["APPBUNDLER_ALLOW_RVM"] == "true")

This prevent using any vendored gem in an habitat packaged binstub as there's no way to tell appbundler to set the GEM_PATH to something specific instead of nil and the binstub can't find its dependend gems because they're neither in core/rubyXX nor the user .gem directory.

Current Alternative

You can manually add the package vendor directory to the GEM_PATH environment variable and set APPBUNDLE_ALLOW_RVM=true to circumvent the issue.

Example for chef-infra_client:

export GEM_PATH=$(hab pkg path chef/chef-infra-client)/vendor:$GEM_PATH
export APPBUNDLER_ALLOW_RVM=true

# Validate chef-client can find its gems
/bin/chef-client -v

Can We Help You Implement This?:

I assume yes, my actual idea would be using another environment variable at build time as such:

custom_gem_path = ENV['ALLOW_CUSTOM_GEM_PATH'] ? ENV['GEM_PATH'] : nil
ENV["GEM_HOME"] = ENV["GEM_PATH"] = custom_gem_path unless ENV["APPBUNDLER_ALLOW_RVM"] == "true")`

This would allow to construct a proper GEM_PATH at build time in habitat packages and let appbundled binstubs works outside of the supervisor control while still using the same GEM_PATH as within the supervisor.

This change shouldn't change actual behavior by still setting nill in the resulting file if the variable ALLOW_CUSTOM_GEM_PATH isn't existing.

Would that be something ok ?

[lamont-granquist]

I don't really understand how that's any better than the current way of doing it...

[Tensibai]

Unsure I get the comment, the idea is to avoid the need to export two variables before launching a command. For that I'd use another variable at build time (when the appbundled binstub is created) to choose to allow or not usage from outside the package.

Actually trying to package a gem with habitat for "distribution only" require to create a wrapper shell script on top of the appbundled binary to set the two necessary variables, I thought that'd be great to allow people to use habitat package as "tool distribution" too.