Skip to content

Use sources as variable #948

Open

Description

@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}}

Activity

  1. added
    good first issueIssues that are good for first-time contributors to pick up.
    and removed
    state: needs triageWaiting to be triaged by a maintainer.
    on Dec 6, 2022
  2. andreynering commented on Dec 6, 2022

    @andreynering
    Member

    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).

  3. jlucktay commented on Oct 4, 2023

    @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}}'
    
  4. callegar commented on Jun 4, 2024

    @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.

  5. added 2 commits that reference this issue on Feb 7, 2025
    ef9ffda
    191cb5d
  6. Cheekie25 commented on Nov 21, 2025

    @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

  7. LuckyJosh commented on Dec 8, 2025

    @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.

  8. added 3 commits that reference this issue on Dec 23, 2025
    229d1aa
    f33da1e
    d3c2f87
  9. assigned and unassigned on Feb 1, 2026
  10. trulede commented on Apr 26, 2026

    @trulede
    Contributor

    I think this issue would be resolved by #2671.

  11. Flimm commented on Jun 18, 2026

    @Flimm

    Note that any solution or workaround needs to be able to handle filenames with whitespace. The user needs to be able to pass an array of strings to a command to be executed, without the unpleasant surprise of seeing arguments further split by whitespace.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    good first issueIssues that are good for first-time contributors to pick up.

    Fields

    No fields configured for feature.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions