fix: restore environment variable precedence and align with docker-compose #417
Conversation
The environment variable precedence was broken in v1.63.0 (PR F1bonacc1#317) where .env file variables were incorrectly given the highest precedence, overriding YAML environment sections. The correct precedence order should be (lowest to highest): 1. System environment (os.Environ) 2. .env file variables 3. Global YAML environment section 4. Local process YAML environment section This fix reorders the environment variable appends in getProcessEnvironment() to restore the correct behavior. The .env variables are now appended before YAML sections, allowing explicit YAML configurations to override .env defaults as originally intended. Changes: - Moved .env variable append block before YAML environment appends - Added comprehensive regression tests (12 test cases) - Preserved is_dotenv_disabled feature from PR F1bonacc1#317 Tests: - All existing tests pass (247/247) - New regression tests verify correct precedence with all 4 sources - Manual verification with real-world configurations confirms fix Fixes: F1bonacc1#416
Replace manual os.Setenv()/os.Unsetenv() calls with t.Setenv() which automatically cleans up environment variables after tests, following Go testing best practices and satisfying the usetesting linter rule.
|
Hey @F1bonacc1! Thanks so much for reviewing and approving this! Really appreciate the quick turnaround. I wanted to mention one thing I noticed while comparing with Docker Compose's behavior - not sure if it's intentional or worth addressing: Shell Environment vs .env PrecedenceI was looking at Docker Compose's environment variable precedence docs and noticed a difference in how shell variables vs .env files are handled. Example scenario: .env file contains: PORT=3000User runs with shell override: PORT=8080 process-compose upCurrent behavior: Uses 3000 (from .env) In Docker Compose, shell/system environment variables have higher precedence than the .env file, but in process-compose it's the opposite (since .env is appended after Since the README mentions process-compose "tries to follow the docker-compose specifications," I wanted to check if this difference is intentional or if it would make sense to align it? If you'd like me to fix this, it's a simple change - I can swap the order in Let me know what you prefer! Thanks again for the great project! |
|
I think that's a very good suggestion. |
Shell/system environment variables now have higher precedence than .env file variables, matching Docker Compose semantics where shell variables can override .env defaults. This provides more flexibility for users to override configuration at runtime without editing files. Changes: - Swapped append order: .env is now added before os.Environ() - Added test case verifying system env overrides .env - Updated precedence comments to reflect correct order Precedence order (lowest to highest): 1. .env file (baseline defaults) 2. System environment (shell overrides) 3. Global YAML environment 4. Local process YAML environment (highest)
F1bonacc1
left a comment
There was a problem hiding this comment.
Looks great!
There is only one small suggestion to one of the comments, to be better aligned with the precedence order.
Co-authored-by: Eugene Berger <[email protected]>
|
Fixes two environment variable precedence issues to restore correct behavior and align with Docker Compose standards.
Issues Fixed
The Problems
Problem 1: .env overriding YAML (Regression)
In v1.63.0 (PR #317), the .env loading refactor inadvertently changed the precedence order. The .env variables were appended last, giving them highest precedence instead of lowest.
Expected: System → .env → Global YAML → Local YAML
Broken: System → Global YAML → Local YAML → .env
Problem 2: .env overriding shell variables
Previously, .env file variables had higher precedence than shell environment variables, preventing runtime overrides.
Example:
The Fix
Reorders environment variable appends in
getProcessEnvironment():Correct precedence (lowest → highest):
This matches Docker Compose behavior where shell variables override .env files.
Testing
t.Setenv()following Go best practicesis_dotenv_disabledfeature from PR Environment variables from .env should not be passed to child processes by default #317Closes #416