Similar request for gofmt. It should accept the ordinary ./... Go project 
recursion syntax, instead of the awkward, explicit:

func GoFmt(args ...string) error {
mg.Deps(CollectGoFiles)

for pth := range CollectedGoFiles {
cmd := exec.Command("gofmt")
cmd.Args = append(cmd.Args, args...)
cmd.Args = append(cmd.Args, pth)
cmd.Stdout = os.Stdout
cmd.Stderr = os.Stderr

if err := cmd.Run(); err != nil {
return err
}
}

return nil
}

In other words, the user should be able to invoke gofmt on a large Go 
project with:

gofmt ./...

Looping over files is a simple enough concept for the tool to implement 
itself, directly. Looping over files in wrapping scripts, such as shell 
code, invites dragons.

On Tuesday, May 21, 2024 at 10:45:14 AM UTC-5 andrew.p...@gmail.com wrote:

> go vet fails to obey the standard PATH environment variable (POSIX, 
> Windows). This makes it unnecessarily cumbersome to use go vet.
>
> Here is an example (Mage) script to scan Go projects for variable 
> shadowing:
>
> func GoVetShadow(args ...string) error {
> shadowPath, err := exec.LookPath("shadow")
>
> if err != nil {
> return err
> }
>
> return GoVet(fmt.Sprintf("-vettool=%s", shadowPath))
> }
>
> The shadow tool is unable to recurse over Go projects with the ordinary 
> ./... syntax; It relies on go vet. And even with the x/tools shadow 
> installed and on PATH, go vet nevertheless requires an absolute path to the 
> program.
>
> Please simplify both of these, so that the user can simply run:
>
> go vet -vettool=shadow
>
> Or:
>
> shadow ./...
>
> Which are easier to remember and lighter on the fingers.
>
> Some gophers will point out that we already have a working solution with 
> Mage, and it's conceivable that equivalents are available in related build 
> systems like make (POSIX, GNU, BSD, etc.) or sh (POSIX, bash, zsh, etc.) 
> However, the requirement for the user to provide an absolute path tends to 
> create maintenance hassles, fragile build scripts, many portability 
> problems, and general resource waste. PATH already provides the 
> information; please stop breaking basic things at the process level.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ba413feb-99d3-401f-b6b9-14c8dad7127dn%40googlegroups.com.

Reply via email to