-
Notifications
You must be signed in to change notification settings - Fork 431
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: env var priority: CLI value should override all others #642
Comments
Thanks for opening this issue! I agree that this is a bug. I believe that most dotenv implementations don't set environment variables that are already present in the environment. As a workaround for now, what does |
Ah!
so that is a workaround! |
I think the way to fix this is to modify This would be a breaking change, so I'm eager to hear from people who use |
In my opinion the change is very welcome, even if it's breaking. I think most people would probably expect that this behavior already is implemented in the first place too |
I'm definitely leaning towards doing this. Is this the norm across other .env implementations? I think it is, but I don't have a ton of experience with any of them. |
so i did some digging to be certain, and it looks to be the norm for node's dotenv they don't override existing variables
for go's godotenv, their Load function (which is used in the usage example), has the same behavior (they also have an Overload function that does override though)
and the same for ruby
so in all these cases if the user supplies the variable themselves, it "wins" over what is in the dotfile |
Thank you very much for the research, eankeen! I think keeping Just's dotenv functionality close to other dotenv implementations is probably what users would most expect, so I added this in #656. Although I don't expect this to be disruptive, this is technically a breaking change, since users could have relied on the .env file overriding environment variables. To reflect this, I bumped the version from 0.6.1 to 0.7.0, and cut a new release with this change. I just tagged 0.7.0, so binaries should be built and uploaded soon by continuous integration. This don't technically fix this issue, since the issue is about CLI vs env variables. However, Just variables, set with |
@casey This change makes sense but only if it includes the overridability used by other tools as well. I believe the |
@runeimp, so if |
I am using just to wrap a legacy build system, which is based on Makefiles. The current workflow is heavily reliant on developers sourcing configuration scripts (ex: Yocto) before running make. This is unpractical for at least two reasons:
This is why I am trying to move towards a just-based workflow with .env for shared configurations and explcit configuration script sourcing only in the relevant recipes. Right now, I am trying to override the PATH from the .env file to expose basic utility tools (starting with make...) to every one. But my modifications are ignored because PATH is already defined in the environment. Would this feature help in my use case? Could you suggest another approach? |
@rohel01 Please don't comment on a 3-year-old issue asking for help or suggestions. This repository has the "Discussions" tab enabled - you can also go to StackOverflow, various programming Discords, etc. |
@hyperupcall The comment just above mine was asking for a use-case so I was providing one. |
Oh sorry, then that's my bad - then it's my appologies for misunderstanding and cluttering this discission |
I would expect the order of env var priority would be (highest taken first):
.env
fileenv_var_or_default(...)
However the
.env
value clobbers the value given on the CLIReproduction:
justfile
:.env
:just
gives:which is to be expected, but
SOME_VAL=fromcli just
gives:instead of:
So there's no way to set env vars on the CLI if they are already set in the
.env
file.The text was updated successfully, but these errors were encountered: