Allow `dotenv` per task

[zx8]

Currently, dotenv is a global configuration.

It would be great if we could specify a different dotenv configuration depending on the task we're invoking in addition to the current global option, similar to how vars and env work.

[shinebayar-g]

Yeah this would work nice since env can be declared at task level. Currently env and dotenv configurations are inconsistent because of this.

[andreynering]

Hi @zx8,

I'm not ure this is a common enough use case. But I'll keep this issue open for a while to collect more opinons.

[andreynering]

~@shinebayar-g That's a valid suggestion, but I suggest you to open another issue about it.~

~Making feature request in comments of an other issue makes it way more likely that this will just be forgotten.~

[zx8]

@andreynering I don't think @shinebayar-g is saying anything different to the OP? They seem to just be reenforcing what I'm suggesting in this feature request.

[andreynering]

@zx8 You're right, I totally misread that comment. I was responding to many issues/comments earlier today and definitely made some confusion.

Sorry.

[rugwirobaker]

I need this 2.

[weeping-somnambulist]

+1 on this.

Use case:

I use Task (exceptional tool btw) to build OCI containers for use with Podman (or Docker). Most images are child images of a parent image. When building a child image, the parent sometimes needs to be re-built for the latest updates. I do use this using the include functionality in Task.

Each image has it's own dotenv file, with a dozen or more variables. As it is now the only way I can re-build a parent image from the child image is to place all the variables in the Taskfile, which is inconvenient and makes the Taskfile much longer and more difficult to read.

Having the dotenv file read at the task level would allow including the parent image for rebuild much easier and simpler, and in my opinion more predictable for the user.

I hope that makes sense.

Thanks!!!!

[Hades32]

In case it helps, this is my current workaround:

  my-task:
    cmds:
    -  npm install
    - |
      export $(grep -v '^\s*#' ./{{.stage}}/env.ini | xargs)
      command --that --needs the-env-vars

[ghostsquad]

I'll plan on doing this in v4 which is my current priority.

[kirinnee]

this has been blocking alot of my work flow massively!

[ghostsquad]

this has been blocking alot of my work flow massively!

Pull requests are welcome!

[ToshY]

I'll plan on doing this in v4 which is my current priority.

@ghostsquad could you give an ETA on v4?

[ghostsquad]

I'll plan on doing this in v4 which is my current priority.

@ghostsquad could you give an ETA on v4?

Due to some divergences in priorities, I've decided to start a new project, https://fngo.dev. It's still in the early stages, as I explore the space, and get a better understanding of current problems, and how I want to solve those problems.

I would say an ETA for the release of fn would likely not be for a few more months. Thanks for your interest!

[noqqe]

Could you give some more details on what that means for task in the future?

[andreynering]

Better to make it clear: I'm the principal maintainer of Task and nothing will change, Task will still be maintained. fngo is an unrelated project by @ghostsquad.

Regarding v4, I couldn't really start it yet because I've being working more on stuff that's possible to ship sooner on v3. In fact, we don't necessarily need to wait for v4 to have this specific feature (I don't know yet if it's more likely to be shipped still on v3 or if it'll be postponed to v4).