go.mod integration as a tool: forward to the declared Task version

[dolmen]

Description

Summary

When working in a Go module where a version of Task is declared as a tool dependency, transfer execution to go tool task.

Rationale

Since Go 1.24 the Go toolchain has special support for versioning tools in go.mod: https://go.dev/doc/modules/managing-dependencies#tools
As Task is written in Go, it can be installed as a tool (see also #2783).
But for a complete integration, it would be better to ensure that task and go tool task run the same version.
So I propose that the task command running from $PATH would delegate to the version of the task command declared in go.mod.

Proposal

When:

1. task detects it works from a Go module (a go.mod is found in a directory up to the directory of the Taskfile.yml config)
2. go env GO111MODULE is not off
3. that go.mod declares a version of task (github.com/go-task/task/v[1-9][0-9]*/cmd/task) in a tool directive: the go tool command lists the declared tools
4. there is a single tool named task declared (avoid ambiguous tool)
5. task isn't already the exact requested version (matching runtime/debug.BuildInfo): avoid useless recursion
6. task has been launched as a simple command (os.Args[0] is not an absolute path, and doesn't even contain a path separator): avoid infinite recursion, and let the user override this behavior

Then:

• Pass all the received arguments (os.Args[1:]) to go tool task and exit

Related issues

• doc: document how to install and use Task in a Go module as a tool #2783
• build(deps): declare ourself as a 'go tool' for ourself #2785
• proposal: cmd/go: tell tools they are being run via go tool golang/go#78673

Implementation hints

Usefull go commands:

• go list tool: list tools declared in the Go module
• go list -f '{{.ImportPath}}{{if not .Module.Main}}@{{.Module.Version}}{{end}}' tool: list tools with their versions
• go list -f '{{.Module.Version}}' github.com/go-task/task/v3/cmd/task: list the requested version of Task

[pd93]

it would be better to ensure that task and go tool task run the same version.

Why? What exactly is the use case/benefit of this?

It feels like hidden behavior to start redirecting to a different version of Task from PATH just because a go.mod specifies a version for the go tool command to use. I have no objection to those who want to use go tool task in their projects, but this is the choice of the user and Task shouldn't make assumptions about what the user wants to do. I can imagine someone running into an issue with this and spending hours of their time only to discover a single sentence that documents this odd behavior.

Task adheres to Semver's rules, so as long as you're running a version of Task that supports all the feature's a project needs, it will work the same way anyway. You don't need to be on an exact version. If your project does require a minimum version of Task then you can define this using the version directive at the top of your Taskfile.

[andreynering]

I agree with @pd93 here.

go tool task is cool, and we can document it as #2783 suggests.

But whether task or go tool task will be ran is user choice.