Imported task cannot call excluded task

[mkantzer]

Description

For the given files:

Taskfile.yaml:

version: 3

includes:
  import:
    taskfile: import.yaml
    excludes:
      - excluded-task

tasks:
  test:
    cmds:
      - task: import:included-task

import.yaml

version: 3

tasks:
  imported-task:
    cmds:
      - echo "howdy"
      - task: excluded-task

  excluded-task:
    cmd: echo "bazz"

Running task test returns:

task: [import:imported-task] echo "howdy"
howdy
task: Failed to run task "test": task: Task "import:excluded-task" does not exist

but when the excludes block is commented out, it returns:

task: [import:imported-task] echo "howdy"
howdy
task: [import:excluded-task] echo "bazz"
bazz

I'd expect task test to return the second result in both cases. I'm using the exclude to prevent excluded-task from showing up in things like autocomplete and task --list-all, but the internal workings of an imported system shouldn't change based on that.

Version

3.41.0

Operating system

macOS

Experiments Enabled

No response

Example Taskfile

[pd93]

@mkantzer Unfortunately, this is another consequence of the way we currently merge taskfiles when resolving includes. This is something that will eventually be solved when we move away from merging. However, there is a lot of work to do to get there.

In the meantime, if you have an internal task that you don't want to show up in --list-all or autocomplete, you could mark it as internal by using internal: true. This will make it so that the task is not directly callable via the CLI which may or may not be desirable in your case.

I will leave this open for now so that we remember to add it as a test case when we remove AST merging.

[vmaerten]

Hello,
I’m a bit confused here because excludes was designed to work this way. It allows a Taskfile with conflicting tasks to be included when using flatten.

Like @pd93 said, mark the task as internal if that’s what you want—it won’t appear in task --list-all and won’t be callable from the CLI.

like this :

Taskfile.yaml:

version: 3

includes:
  import:
    taskfile: import.yaml

tasks:
  test:
    cmds:
      - task: import:included-task

import.yaml

version: 3

tasks:
  imported-task:
    cmds:
      - echo "howdy"
      - task: excluded-task

  excluded-task:
    internal: true
    cmd: echo "bazz"

To me internal does what you want, and it's not the same behavior as excludes

To finish, I'd quote our doc :

Maybe we need to clarify that it won't be callable not only from the CLI but also from within a Taskfile.

We could change this behavior, but what would be the difference with internal in this case ?

Feel free to jump in @pd93

[pd93]

@vmaerten The docs make it clear that if you have taskfile A which includes taskfile B (containing foo and bar) and you exclude B.bar from the include, then task B.bar will not be available to call from taskfile A. However, it doesn't define whether or not calling task B.foo (which is not excluded) can subsequently call B.bar which is what I believe @mkantzer is describing.

I can understand why this distinction is confusing as includes can be thought of as an import where excludes removes a task from the import, but does not stop it from existing all-together (i.e. it still exists in the scope of taskfile B and could be called from other tasks in that taskfile).

However, this is not currently the case. excludes will currently stop that task from being callable from anywhere. I'm not sure if this is the desired behavior or not.

This is quite a complex issue to describe, so sorry if I'm not clear. I rewrote this twice 😆

[mkantzer]

@pd93 you've got it exactly: something like having private functions.

That being said, using internal will accomplish exactly what I want, and in a cleaner way by keeping the setting in the included Taskfile.

Appreciate the help. Feel free to keep this open as a reference for after AST merging removal if you still need it.

[vmaerten]

Thanks a lot ! It's cristal clear 🙂
Like for variables we come back at this scoping issue.