[go-nuts] Re: vet: Respect PATH

2024-05-21 Thread andrew.p...@gmail.com
Same request for goimports.

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

for pth := range CollectedGoFiles {
cmd := exec.Command("goimports")
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
}

Instead of the above nonsense, the user should be able to scan a large Go 
project with:

goimports ./...

Maybe these features have been added in recent Go versions. If so, please 
comment which specific Go versions finally added basic directory recursion 
to more of these tools.

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

> 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/537fe765-873c-417c-b74d-772e33c3dc23n%40googlegroups.com.


[go-nuts] Re: vet: Respect PATH

2024-05-21 Thread andrew.p...@gmail.com
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.