Any variables experiment about task HOT 19 OPEN

Is it wanted behaviour, that nested keys in objects aren't templated?

Hi @cwrau, could you please provide an example Taskfile with what you're seeing and what you expected to see. This will help me better understand what the problem you're having is.

vars:
  image:
    tag: '{{ .IMAGE_TAG | default "latest" }}'

When used later, it just contains the string {{ .IMAGE_TAG | default "latest" }}

from task.

@cwrau @toby-griffiths If you have some time, please try out the changes #1526. They should address your comments/issues. If you have Go installed, you can try the version in the PR by running:

go install github.com/go-task/task/v3/cmd/task@4bf9c78

Mh, doesn't appear to be working?

version: '3'
vars:
  cheese:
    cake: chocolate
  cheesecake: chocolate
tasks:
  not-working:
    cmd: echo {{ printf "%s" .cheese.cake }}
  working:
    cmd: echo {{ printf "%s" .cheesecake }}

$ TASK_X_ANY_VARIABLES=1 task not-working
task: [not-working] echo %!s(*string=0xc00021ac40)
$ TASK_X_ANY_VARIABLES=1 task working
task: [working] echo chocolate

Also, if you have any other general feedback on the experiments, I'd be very keen to hear it. Particularly with regard to the two different proposals and how they handle map variables. Thanks

I'm definitely in favor of variant 1, it just seems more natural to define variables that way and dynamic variables are a special case, so prepending $ also kinda makes sense

from task.

@cwrau Thanks for testing. I made a small mistake in my implementation. It worked when using a variable directly (e.g. {{.cheese.cake}}) so I assumed everything was ok, but nested values were being returned as pointers instead of values so when printing .cheese.cake the type was a *string instead of a string - hence the printf error.

Can you please try again with: go install github.com/go-task/task/v3/cmd/task@3109a89

That's now working, but the following isn't;

version: '3'
vars:
  cheese:
    cake: chocolate
    type: '{{ .cheese.cake }}'
  cheesecake: chocolate
  cheese_type: '{{ .cheesecake }}'
tasks:
  not-working:
    cmd: echo {{ printf "%s" .cheese.type }}
  working:
    cmd: echo {{ printf "%s" .cheese_type }}

$ TASK_X_ANY_VARIABLES=1 task working
task: [working] echo chocolate
chocolate
$ TASK_X_ANY_VARIABLES=1 task not-working
task: [not-working] echo 

from task.

This issue has been marked as an experiment proposal! 🧪 It will now enter a period of consultation during which we encourage the community to provide feedback on the proposed design. Please see the experiment workflow documentation for more information on how we release experiments.

from task.

Thanks for opening this issue!

Some small comments:

• CLI_ARGS is intentionally a string, so it's as easy as possible to delegate arguments like yarn {{.CLI_ARGS}}. We should keep it as a string for this use case, but we can set an additional var which would be an array.
• There's an irony of suggesting $ as a prefix for variables, because that's how Task detected commands in the beginning, but it was eventually deprecated in favor of sh: 🙂. We would be returning to its origins. Perhaps there's a better than way than that prefix, but I'm out of ideas at the moment.

from task.

• CLI_ARGS is intentionally a string, so it's as easy as possible to delegate arguments like yarn {{.CLI_ARGS}}. We should keep it as a string for this use case, but we can set an additional var which would be an array.

Ok, that makes sense. I'll remove this section for now. We can revisit down the line if necessary. This reduces the amount of breaking changes.

• There's an irony of suggesting $ as a prefix for variables, because that's how Task detected commands in the beginning, but it was eventually deprecated in favor of sh: 🙂. We would be returning to its origins. Perhaps there's a better than way than that prefix, but I'm out of ideas at the moment.

I don't think I knew about Task in the days before sh, but I actually agree. I'm not convinced by this syntax and it seems like it could cause problems/confusion. However, I'm not entirely sure what a good alternative is either. I suggested this approach as there appeared to be some consensus in #140. However, the comments there are quite old, so perhaps a fresh think about this is in order.

There is always the option of not supporting maps initially. This would actually mean that we could release this without a major version bump as I don't think there would be any remaining backward-incompatible changes.

from task.

This experiment has been marked as a draft! ✨ This means that an initial implementation has been added to the latest release of Task! 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.

from task.

Hi !
Thanks a lot for your work on it! It's really appreciated. I will give it a try, because map is something I wanted to use.
I just see you made a PR about looping over map, that's also a great thing!

If you are interessed in, I can post a use case of it

from task.

Thanks for the great work on Taskfile.

I'm having issues suporting proposal 2 (not tested porposal 1 yet.

Here's my Taskfile, containing one of the examples given…

version: '3'

tasks:
  foo:
    desc: test
    vars:
      FOO:
        map: { a: 1, b: 2, c: 3 } # <-- Defined using the `map' subkey instead of directly on 'FOO'
      BAR: true # <-- Other types of variables are still defined directly on the key
      BAZ:
        sh: 'echo Hello Task' # <-- The `sh` subkey is still supported
    cmds:
      - 'echo {{.FOO.a}}'

When I attempt to call task --list-all I get the following error…

template: :1:11: executing "" at <.FOO.a>: can't evaluate field a in type interface {}

Task version: v3.33.1 (h1:JJSRANHH7RQrr5Z2CTvSnTH7iWlfBlKV2W2O0JiZoLk=)

And here's my .env file in the same directory…

TASK_X_ANY_VARIABLES=2

What am I doing wrong?

from task.

Hi @toby-griffiths.

Firstly, thanks for trying this out. Definitely looking for some feedback on these experiments.

Secondly, apologies for any confusion. v3.33.1 does not contain support for the 2nd proposal and this change has not been included in any release yet. Unfortunately, we still haven't versioned our docs, so they are more up to date than Task itself (This is something we need to resolve).

If you are using Go to install Task, then you can run go install github.com/go-task/task/v3/cmd/task@main to grab the latest commit from main. This will allow you to try it out before we do the next release. You can verify that the proposal experiment is enabled by running task --experiments and you should see this:

* GENTLE_FORCE:     off
* REMOTE_TASKFILES: off
* ANY_VARIABLES:    on (2)

Just be aware that unreleased versions (particularly experiments) might be a bit buggy. Not a problem if you're just trying stuff out though.

from task.

Ah, thanks @pd93 I'll try installing via go (I had used Homebrew).

In case it's useful info, I've also just tried the following proposal 1 example…

version: '3'

tasks:
  foo:
    vars:
      ARRAY: [ 1, 2, 3 ]
    cmds:
      - 'echo {{range .ARRAY}}{{.}}{{end}}'

… to receive the error…

yaml: line 13: cannot unmarshal !!seq into variable

So not sure if this is related or a separate issue?

from task.

@toby-griffiths Your example works for me on v3.33.1.

❯ TASK_X_ANY_VARIABLES=1 task foo 
task: [foo] echo 123
123

The error you're getting is symptomatic of the experiment not being enabled, so I suspect that we're not reading your .env file correctly. You can run task --experiments to check this.

Are you by any chance using the --taskfile or --dir flags in the command that you're running? Where is your .env file located relative to your Taskfile.yml? and what directory are you in when you run the command relative to your Taskfile.yml?

from task.

@pd93 So I checked and it reported that the experiment was there an enabled, yet I got that error.

I've since installed the Go version and it's working fine with both proposales.

I also found that spew didn't seem to work with the Homebrew version, so I wonder if that's just not all there, somehow?

I wasn't using --dir or --taskfile when calling task, and the .env file was in the same directory as the Taskfile.yaml.

I'm using .yaml rather than .yml, but that shouldn't matter, right?

from task.

@pd93 So I checked and it reported that the experiment was there an enabled, yet I got that error.

Ah, I just realised, this is probably related to #1463 which would explain why it's fixed when you tried main. This will be resolved in the next version.

I also found that spew didn't seem to work with the Homebrew version, so I wonder if that's just not all there, somehow?

spew will be in the next release too.

I'm using .yaml rather than .yml, but that shouldn't matter, right?

This shouldn't make a difference. They are equivalent.

I've since installed the Go version and it's working fine with both proposales.

Please let us know how you find them!

from task.

Is it wanted behaviour, that nested keys in objects aren't templated?

And how can I set a nested variable from the outside, e.g. via environment variables or some kind of flag?

from task.

Is it wanted behaviour, that nested keys in objects aren't templated?

Hi @cwrau, could you please provide an example Taskfile with what you're seeing and what you expected to see. This will help me better understand what the problem you're having is.

And how can I set a nested variable from the outside, e.g. via environment variables or some kind of flag?

This is outside of the scope of this experiment. Currently only string types are supported from environment variables. However, I'd be open to proposals on how this could work in a future improvement!

from task.

@cwrau @toby-griffiths If you have some time, please try out the changes #1526. They should address your comments/issues. If you have Go installed, you can try the version in the PR by running:

go install github.com/go-task/task/v3/cmd/task@4bf9c78

Also, if you have any other general feedback on the experiments, I'd be very keen to hear it. Particularly with regard to the two different proposals and how they handle map variables. Thanks

from task.

@cwrau Thanks for testing. I made a small mistake in my implementation. It worked when using a variable directly (e.g. {{.cheese.cake}}) so I assumed everything was ok, but nested values were being returned as pointers instead of values so when printing .cheese.cake the type was a *string instead of a string - hence the printf error.

Can you please try again with: go install github.com/go-task/task/v3/cmd/task@3109a89

from task.

@cwrau Thanks again. I've merged the changes in #1526 as I think the functionality added there is useful by itself. It's a bit more complicated to do what you've described in #1415 (comment), so I've opened #1544 to track this separately. Let's move any further discussion about this functionality to that issue.

from task.