Description:
kas intentionally uses a controlled environment to support reproducibility and reduce host contamination. However, this default behavior is not made explicit enough in the documentation.
The docs describe the mechanisms to manage environment variables (for example, the env key and -E/--preserve-env), but they do not clearly state the default behavior up front: variables exported in the host shell are not generally inherited by default.
Problem / User Impact
New users often expect shell-exported variables to be available in kas build or kas shell.
When those variables are missing, troubleshooting can take longer than necessary because the behavior is not obvious unless users infer it from:
- the existence of
-E/--preserve-env
- source code inspection
- trial and error
This creates an avoidable onboarding hurdle.
Proposed Documentation Change
Add something like:
By default, kas does not inherit the full host shell environment into the build environment.
Instead, kas constructs a controlled environment to improve reproducibility and reduce host contamination.
If specific variables are needed, define them in the env section of the kas configuration, or use -E/--preserve-env for interactive one-off sessions.
If the maintainers agree that this is the right direction, we would be happy to submit a PR with a proposed documentation update.
Description:
kasintentionally uses a controlled environment to support reproducibility and reduce host contamination. However, this default behavior is not made explicit enough in the documentation.The docs describe the mechanisms to manage environment variables (for example, the
envkey and-E/--preserve-env), but they do not clearly state the default behavior up front: variables exported in the host shell are not generally inherited by default.Problem / User Impact
New users often expect shell-exported variables to be available in
kas buildorkas shell.When those variables are missing, troubleshooting can take longer than necessary because the behavior is not obvious unless users infer it from:
-E/--preserve-envThis creates an avoidable onboarding hurdle.
Proposed Documentation Change
Add something like:
If the maintainers agree that this is the right direction, we would be happy to submit a PR with a proposed documentation update.