Environment variables from shell takes precedence over task file definition

Hey 👋

I guess I have found a bug yesterday on task: It looks like previously defined environment variable are not overwritten by the definition within the task file.

Taskfile

version: '3'

silent: true

tasks:
  default:
    env:
      KEY: 'other'
    cmds:
      - echo "$KEY"

Expected

I would expect the environment variable of KEY to be overwritten whatever the outside environment looks like.

$ task
other
$ KEY=some task
other

Actual

The environment variable from the outside shell takes precedence over the variable defined within the taskfile.

$ task
other
$ KEY=some task
some

Os + Taskfile-version

$ cat /etc/lsb-release 
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=21.1
DISTRIB_CODENAME=vera
DISTRIB_DESCRIPTION="Linux Mint 21.1 Vera"
$ task --version
Task version: v3.21.0 (h1:pVGAGXxJ9Pk5mvjqv/CsdAD4ZIzNMjF+vrXMueM/WFk=)

Why is that problem?

I have not found any reference to that behavior in the docs.
I love to clearly define my environment when using task rather than relying on any other outer state. In that case it's impossible to overwrite previously defined variables which may be a huge issue.

Any feedback on this?

I also just ran into this and was also surprised

Unfortunately, this is a breaking change. This means we'd have to wait for the next major version release to do this by default, and that can take quite some time to happen.

In the meantime, we can consider having an opt-in setting for the behavior, so those who want to anticipate that can just set a flag.

In my opinion this is a bug. If I set a variable in the command I expect it to run with this configuration. Otherwise the stuff I see in the Taskfile is not what is happening when running the task. This is really confusing for the user.

If you are not willing to change the behavior because of backward compatibility concerns I would prefer to set the opt-in option in the Taskfile, otherwise when I forget it, commands are not working.

@zbindenren

Thanks for your feedback!

I kindly agree with @zbindenren considering it a bug.

I also agree that this may be a breaking chance in respect of current behavior even though it was never documented.

I would argue that my pull request is not relevant anymore in respect of the direction you are suggesting.
Shall I close it?

Nevertheless I would consider documenting (and also adding tests) the current behavior as useful.
When creating the PR changing the behavior it did not break any test.

Shall I put some effort into that?

@jaedle

@jaedle I'm sure that some people like and use the current behavior. So, if you're willing to work on it, I think we should have a setting on the Taskfile to opt-in the new behavior. Something like:

disable_os_env_precedence: true

(Consider this name WIP. Naming things is hard. Suggestions are welcome. 🙂)

/cc @pd93. I think you had some ideas on how to deal with breaking changes and flags like this. This may be an opportunity to start discussing it.

@andreynering

@andreynering yes, I've actually started writing up a proposal for breaking changes, but didn't have much time to work on it last week. I'll see if I can get it sorted in the next day or two and I'll link it back to here when I've posted it.

Very quick thoughts:

I'm not a huge fan of adding experimental flags to the Taskfile itself. I think it can muddy the schema a lot - especially if the behaviour may change or be removed entirely in a future major release. However, if we're proposing a permanent change (i.e. users will be able to make this choice going forwards into new major versions), then I don't consider this to be a breaking change at all (as long as the default behaviour stays the same). We can always have a discussion about changing the default behaviour at a later date.

Since this is a hotly debated topic, it might be nice to put this behind an experimental flag before making it a permanent feature of the Taskfile so that users can try it out. That way, we're not making more breaking changes in the future if it's not implemented to everyone's liking. This kind of flag would be enabled with a TASK_X_ENV_PRECEDENCE envvar. This allows users to try out the behaviour with one-off commands (via flag) or by setting up their environment (envvar).

As I said, I'll post something with much more detail soon.

Thanks for your feedback! This is really appreciated.

As we are not sure about the direction up l would feel free to document the current behaviour in tests + docs, if you are fine with it.

@andreynering

@andreynering @jaedle @zbindenren Apologies for the delay, I've been travelling for work a lot lately, but I had some time today to write up the breaking changes proposal. Comments/thoughts are very welcome

@pd93

The proposal lgtm @pd93 . Nice work. Maybe some additional thoughts:

how long is a flag experimental? Maybe we should do it like kubernetes does. 3-6 months and then it is dropped or added.
how do we introduce breaking changes to the taskfile yaml itself. Maybe define when and how and under what circumstances to relaease a v4 etc...

@zbindenren

Maybe some additional thoughts:

@zbindenren replied to your comments in the proposal discussion to keep everything together.

This experiment has been marked as stable! 🤘 This means that the implementation is now final and ready to be released. No more changes will be made and the experiment is safe to use in production! You can find information about this experiment and how to enable it in our experiments documentation. Please see the experiment workflow documentation for more information on how we release experiments.

Please note that while this is ready to be released, it is also a breaking change and so will be released generally for the next major version of Task which does not have an ETA at this time. For now, you will need to continue to enable the experiment.

Of course, we will update here if/when this changes :)

If this is now a "stable" experiment, should support be added for enabling this via a "feature flag" in the taskfile.yml file? This can be done in a backwards-compatible way, and then in the next major version, this feature flag would change from default-off to default-on?

@GrahamDennis

@GrahamDennis Experiments can already be enabled in a couple of different ways. At this time, we do not have any plans to add experiments to the main Taskfile schema. See #1978 for more discussion on this.

The docs still discourage the use of this feature: https://taskfile.dev/docs/experiments/env-precedence

Should the docs be updated to no longer discourage its use?

Navigation Menu

Repository navigation

Environment variables from shell takes precedence over task file definition #1038

Taskfile

Expected

Actual

Os + Taskfile-version

Why is that problem?

37 remaining items

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Environment variables from shell takes precedence over task file definition #1038

Description

Taskfile

Expected

Actual

Os + Taskfile-version

Why is that problem?

Activity

jaedle commented on May 1, 2023

matthchr commented on May 3, 2023

andreynering commented on May 23, 2023

zbindenren commented on May 23, 2023

jaedle commented on May 23, 2023

andreynering commented on May 23, 2023

pd93 commented on May 23, 2023

jaedle commented on May 26, 2023

pd93 commented on May 27, 2023

zbindenren commented on May 30, 2023

pd93 commented on May 30, 2023

37 remaining items

task-bot commented on Jan 24, 2025

pd93 commented on Jan 24, 2025

GrahamDennis commented on Mar 16, 2025

pd93 commented on Mar 16, 2025

merusso commented on Sep 20, 2025

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions