env vars set in Invoke-SetupEnvironment cannot leverage paths in /hab when built in a local windows studio

[mwrock]

I might want to have this in a windows plan:

function Invoke-SetupEnvironment {
    Push-RuntimeEnv "PSModulePath" "\hab\pkgs\$pkg_origin\$pkg_name\$pkg_version\$pkg_release\Modules"
}

The problem is that in a windows studio \hab\pkgs will resolve to the wrong path in a local windows studio because it will not be FS_ROOTed. Likewise I cannot make use of $pkg_prefix for the inverse reason: it WILL be FS_ROOTed and will therefore not work outside of the studio.

Ideally we would have a similar means of handling these paths as we do for bin_dirs, lib_dirs, and include_dirs where we resolve the paths at runtime relative to the current FS_ROOT.

[robbkidd]

I believe I've hit this issue, too. I'm attempting to package a Ruby command line application (you may have heard of it) on Windows. To facilitate the app package behaving like both a library and like a service, I need to be able to add the gems installed into my app—in say, the <pkg_prefix>\vendor directory—to the runtime GEM_PATH of my app and any app that depends on mine.

"Cool!" I think. "I'll use the SetupEnvironment!" No joy.

# in my plan:

function Invoke-SetupEnvironment {
    Set-BuildtimeEnv GEM_HOME "$pkg_prefix\bundle"
    Push-RuntimeEnv GEM_PATH "$pkg_prefix\bundle"

    Set-RuntimeEnv SSL_CERT_FILE "$(Get-HabPackagePath cacerts)/ssl/cert.pem"
    Set-RuntimeEnv LANG "en_US.UTF-8"
    Set-RuntimeEnv LC_CTYPE "en_US.UTF-8"
}

The resultant RUNTIME_ENVIRONMENT has paths into which the studio's path have leaked.

PATH=\hab\pkgs\robbkidd\chef-infra-client\15.2.4\20190725191821\bin;
     \hab\pkgs\core\git\2.20.1\20190223004934\bin;
     \hab\pkgs\core\openssl\1.0.2r\20190305191131\bin;
     \hab\pkgs\robbkidd\ruby-plus-devkit\2.6.3\20190725174341\bin
GEM_PATH=C:\hab\studios\work\hab\pkgs\robbkidd\chef-infra-client\15.2.4\20190725191821\bundle;
         C:\hab\pkgs\robbkidd\ruby-plus-devkit\2.6.3\20190725174341\lib\ruby\gems\2.6.0
SSL_CERT_FILE=C:\hab\studios\work\hab\pkgs\core\cacerts\2017.01.17\20170209064044/ssl/cert.pem
LANG=en_US.UTF-8
LC_CTYPE=en_US.UTF-8

• PATH looks great. No drive letter or extra directories before the \hab root.
• GEM_PATH ... not so much.
  • The drive letter of the studio gets in there in regardless of studio type: Windows native (the chef-infra-client entry) and Docker (the ruby-plus-devkit entry). I understand that habitat can be installed to drives other than C: in runtime environments.
  • The Windows native studio includes the studio path in $pkg_prefix during build. So it includes C:\hab\studios\work or from wherever the studio was entered.
• SSL_CERT_FILE is also tainted by the native studio path when $(Get-HabPackagePath cacerts) was used.

[mwrock]

The supervisor includes "special" logic when setting PATH and knows to resolve each path rooted against the environment's FS_ROOT. It seems like what we need is a way to hint that a variable's value is a path that needs to be rooted according to its runtime environment.

Perhaps we could expose a -resolve-FS_ROOT flag to Set-RuntimeEnv and Push-RuntimeEnv that would provide such a hint. Just thinking off the top of my head, these variables may go in a ROOTED_RUNTIME_ENVIRONMENT file that the supervisor would use to apply PATH-like logic to those variable values.