task
task copied to clipboard
Changing PATH env var doesn't seem to work
- Task version: 3.2.2
- Operating System: MacOS & Linux
Firstly thanks a lot for the excellent tool! I've moved lots of hacky shell scripts over to task.
Example Taskfile showing the issue
version: "3"
env:
PATH: test
tasks:
path:
- echo $PATH
The result is my existing path. Switching from PATH
to PATH2
shows test
as expected. Is this intentional?
afaik, it is not possible to override environment variables, and this is expected. I asked in https://github.com/go-task/task/discussions/449 whether it'd be possible to add this change in a PR, but the question hasn't been answered. I'd be happy to contribute with this but would like to know first if @andreynering would be open to have a PR with these changes.
@ivotron Well you can try to implement this and maintain change at least in your fork. As for me will pull this change to mine for sure.
To me, it seems like the more correct way might be to opt-in to the inheritance.
env:
PATH: $PATH
I think the closest parallel would be a Dockerfile, where the stacking goes:
- ENV directive
-
.env
file -
-e
flag
I think the interactions for most of this is underspecified. And the "$" in env: actually is equivalent to { sh: }
.
Hi everybody,
Changing the priority order of ENVs is a breaking change and would be unexpected to existing users that rely on it. Currently it's possible to override ENVs with something like env MY_ENV=overriden task foo
. This proposal would break that.
Making this change would make ENV work similar to VARS regarding its priority, but would require people to use MY_ENV: '{{default FOO .MY_ENV}}'
on all ENV declarations that should be overridable. This could be inconvenient for some and would likely require a release of v4 since it's a breaking change. The same applies to #521.
I would love to hear opinions on what do you think. An alternative would likely be better than a breaking change. Let me know if you have any ideas on how to do that.
Regarding the ability to override PATH, as a workaround you could have a variable with the prefix command:
version: '3'
vars:
PREFIX: env PATH="/some/path:$PATH"
tasks:
foo:
cmds:
- '{{.PREFIX}} my command'
- '{{.PREFIX}} another command'
Perhaps https://github.com/go-task/task/issues/204#issuecomment-495946056 would be nice to have this workaround cleaner.
I just found this, and this feels like a pretty big issue. Here's the simplest case:
version: '3'
tasks:
one:
env:
HAM: one
cmds:
- echo $HAM
two:
cmds:
- task: one
env:
HAM: two
at 13:41:58 ❯ task -t Taskfile.tmp.yml one
task: [one] echo $HAM
one
at 13:42:09 ❯ task -t Taskfile.tmp.yml two
task: [one] echo $HAM
one
I also tried this:
version: '3'
tasks:
one:
env:
HAM: '{{env "HAM" | default "one"}}'
cmds:
- echo $HAM
two:
cmds:
- task: one
env:
HAM: two
The following DOES work:
version: '3'
tasks:
one:
vars:
HAM: '{{.HAM | default "one"}}'
env:
HAM: '{{.HAM}}'
cmds:
- echo $HAM
two:
cmds:
- task: one
vars:
HAM: two
Which leads me to believe that really vars
should be used more liberally than env
, and env
should always derive from vars
, because then you can do this:
version: '3'
vars:
HAM: '{{env "HAM"}}'
tasks:
...
Which would allow the make
behavior of HAM ?= default-value-here
It seems there are many related issues to this as well: #591, #658, #630, #593, #191
@andreynering
change and would be unexpected to existing users
Have you considered adding an override_env
variable in the global scope
which by default will be false (same order as now)
but if true, it will handle replacing existing envs (for example with PATH)
it would not be such a big change to increase the version to v4, but it also allowed to solve this problem
and in the future, simply version v4 will be the default value of true
version: "3"
override_env: true
env:
PATH: test
tasks:
path:
- echo $PATH