Use sources as variable

[NVolcz]

For a task, is the list of files specified in sources available for commands so it can be used as a variable?
I have a script that that I would like to pass the list of sources available to:

version: '3'

tasks:
  test:
    cmds:
      - echo {{.sources}}
      - ./test/shellcheck.sh {{.sources}}
    sources:
      - *.sh

Alternatively if it was possible to use vars for sources:

version: '3'

tasks:
  test:
    cmds:
      - echo {{.sources}}
      - ./test/shellcheck.sh {{.sources}}
    vars:
      SCRIPTS:
        sh: find . -iname '*.sh' -not -path './cygwin/*' | xargs echo
    sources:
      - {{.BASH_SCRIPTS}}

[andreynering]

Hi @NVolcz,

This indeed makes sense, because we already have other special variables like TASK, TIMESTAMP and CHECKSUM.

Implementation note: this variable should probably be an array (slice) because them users will have more flexibility on what to do with it (join with space or ,, loop through it, or other). TIMESTAMP is already of a different type (time.Time).

[jlucktay]

I think this might help with a use-case I'm looking at now.
I discover go.mod files and put the results into a GO_MODULES variable at the top level of Taskfile.yaml.
Then there are tasks using cmds.for.var to execute something in each of the GO_MODULES directories.
I would like the tasks to be able to look at sources with globs relative to each of the GO_MODULES items as each iteration of the for loops run.

edit: never mind, a colleague came up with a pattern for what I want to do that works quite well as-is:

  do-thing:singular:
    desc: Run a single thing
    requires:
      vars:
        - THING
    sources:
      - 'subdir/{{.THING}}/**/*.{go,mod,sum}'
    cmds:
      - task: gotest
        vars:
          GOTESTVAR: './subdir/{{.THING}}/...'

  do-thing:plural:
    desc: Run several things
    requires:
      vars:
        - THINGS
    cmds:
      - for: { var: THINGS }
        task: do-thing:singular
        vars:
          THING: '{{.ITEM}}'

[callegar]

Wonder if this is the only possible solution. May I suggest:

• having a way to define array variables by the same glob mechanism that is now possible with sources, maybe with a suitable template function.
• having a way to use array variables for sources.

IMHO this would be more flexible since it would let any variable be usable based on filename expansion.

[Cheekie25]

Hello.

Task seems great but I'm very surprised this is not yet possible for a tool that aims to replace GNU Make.
So many of my Make recipes use $^ variable and I don't see any way to migrate to Task before this is implemented.

Do you have any workaround when you need to pass the whole list of sources to a command of a rule at the same time (and not one by one which I saw is possible with the for keyword) ?

Thanks

[LuckyJosh]

I was just wandering about this (just like @Cheekie25, I often use/used the (cryptic) shorthand notation in make).
I guess it would make sense to add the variable TASK_SOURCES but I thought of a "workaround" that seems
actually less error prone[1]:

Defining the source and generated files as variables first
and then add the variables in sources/generates respectivly.

My minimal working example:

version: '3'
tasks:
  default:
    vars:
      src_file_a: file-a.txt
      src_file_b: file-b.txt
      src_file_c: file-c.txt
      gen_file_ab: "file-ab.txt"
      gen_file_bc: "file-bc.txt"

    sources:
      - "{{.src_file_a}}"
      - "{{.src_file_b}}"
      - "{{.src_file_c}}"
    generates:
      - "{{.gen_file_ab}}"
      - "{{.gen_file_bc}}"
    method: timestamp

    cmds:
      - cat {{.src_file_a}} {{.src_file_b}} >> {{.gen_file_ab}}
      - cat {{.src_file_b}} {{.src_file_c}} >> {{.gen_file_bc}}

[1] The variable TASK_SOURCE would probably just be an array, so the position of the source files in the list would matter. This workaround names each source so it is not dependent on the order.
The best of both worlds would be if you could define sources/generates as associative arrays, i.e. the sources/generates
would define variables without the extra step through vars.