search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
122.71k stars 17.5k forks source link

proposal: go install: allow whitespace delimited package names from separate modules and versions #59549

Open mcandre opened 1 year ago

mcandre commented 1 year ago

I would like to be able to run:

go install \
    github.com/alexkohler/nakedret@v1.0.1 \
    github.com/kisielk/errcheck@v1.6.3 \
    github.com/magefile/mage@v1.14.0 \
    github.com/mcandre/factorio/cmd/factorio@v0.0.3 \
    golang.org/x/lint/golint@latest \
    golang.org/x/tools/cmd/goimports@latest \
    golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow@latest \
    honnef.co/go/tools/cmd/staticcheck@2023.1.3

go mod tidy

Like I can with other common package managers (apt, yum, brew, cargo).

However, Go currently has this policy prohibiting this invocation. So I have to instead write down the same package commands in a longer boilerplate:

go install github.com/alexkohler/nakedret@v1.0.1
go install github.com/kisielk/errcheck@v1.6.3
go install github.com/magefile/mage@v1.14.0
go install github.com/mcandre/factorio/cmd/factorio@v0.0.3
go install golang.org/x/lint/golint@latest
go install golang.org/x/tools/cmd/goimports@latest
go install golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow@latest
go install honnef.co/go/tools/cmd/staticcheck@2023.1.3

go mod tidy

Can we please remove the current restriction against asking go install to request separate modules and versions per run?

No, I don't want to use an alias or other shim. That introduces fragility and vendor locks provisioning scripts.

When go mod eventually standardizes built-in support for pinning dev dependencies, then that would somewhat mitigate the need for this feature in go install. But this feature would still serve as a good complement to go mod, regardless.

ianlancetaylor commented 1 year ago

CC @bcmills @matloob

mvdan commented 1 year ago

Note that installing multiple packages from different modules in a single command is not the same as doing it via separate commands. Each go install or go build invocation results in a single build context, i.e. a single MVS resolution to find all modules to download and packages to build.

I personally run many go install pkg@latest & commands and then wait for all of them. This doesn't mix their dependency versions via MVS, the concurrency works fine thanks to file locking in the build cache, and I don't really notice the overhead of running cmd/go many times.

Agreed that the UX is perhaps not great, but the current restriction is there for a good reason, and lifting it without a second thought will cause confusion and unintended consequences.