One more comment for everyone: this feature is implemented at tip in CL 254365. You can try it out with golang.org/dl/gotip. Please experiment and let us know how it works for you.

There's a little more than a month before the 1.16 freeze (November) to make significant changes, and we'll have about a month after that before 1.16beta1 (December) to find and fix bugs.

@thepudds

I'm open to editing the proposal to discuss future modifications. The two possible paths we could take are 1) ignoring replace directives, or 2) applying only module replace directives, still reporting an error if a directory replace directive is present.

It would be good to talk about what kind of data would convince us to take one path or the other.

For (1), we should see how much of a hassle it is for authors to edit go.mod for release versions.

For (2) applying module replace directives, I'd like to be sure that modules that depend on tool-providing modules won't be seriously impacted by additional replace directives. I think we need a better story for tool dependencies in general (for example, an enhanced go run pkg@version or a new kind of require-like directive for tools. That won't happen for 1.16, so I'd like to defer making a decision on that for now.

Anything else on your mind in this area?

@aarzilli

Just to be clear, this is its current behavior, not the new behavior being proposed here?

Yes. Currently, all module commands honor replace and exclude directives in the main module's go.mod file, that is, the go.mod file in the current directory (or any parent). replace and exclude directives in all other go.mod files are ignored.

But if you run go install example.com/A/pkg from inside example.com/A/pkg does it use require and replace directives from its own go.mod file?

Yes. If example.com/A is the main module, then its replace directives apply.

I have a better solution go install example.com/A/pkg always applies require and replace directives from example.com/A/pkg, this way go install, go build and go test all behave the same way.

go build and go test don't work that way. No module command does.

This would completely change the interpretation of replace, and it would break a lot of modules.

Could you rewrite the proposal to make it clear where you are talking about current behavior of go install and where you are talking about proposed new behavior of go install?

The new behavior is specified carefully in the "Proposal" section. The current behavior is explained in "Current go install and go get functionality".

You may also want to read the reference documentation for more clarity on the current behavior:

• replace directive
• Replacement
• go get
• Build commands

I think we both agree that it's wrong since you are proposing that the new thing should error when it encounters a replace directive.

I don't agree.

My personal opinion is that go install pkg@version should ignore all replace directives. That would make it behave like go get does when invoked in module mode outside a module. That would let module authors leave replace directives in place in release versions, knowing that they wouldn't affect users.

As I mentioned earlier though, this proposal was a compromise, and we decided to go with something very strict. If we find that's not the right behavior, we can relax it a bit, either by ignoring replace directives or applying module replace directives only.

What you are saying it is that go build example.com/some/package is going to apply replace/require directives from the current directory, even if the current directory has nothing to do with example/com/some/package. How often do you think this behavior is used? Do you think this is what users expect to happen? What if instead it always applied the replace/require directives of example.com/some/package?

No change to go build is proposed here. This is already the current behavior, and it's used all the time.

I certainly hope people expect this. If I run go build example.com/A/pkg from my main module example.com/Main, and the main module replaces example.com/A, I'd expect to build the package from my replacement, not something else.

Ok, but we are talking about tool dependencies here and we have already established that there are better ways to solve that problem that using a global install command to manage local dependencies. So this isn't a problem, the module user, in this case, can use go mod run-external-tool (or whatever it gets called) to build and run the external tool with requires and replaces from the current go.mod file applied.

They can use go run, go build, or go install as they work today. No change is being proposed for this use case, and I don't see any reason to break it.

We are talking about it here because we're specifically trying to avoid breaking it.

I think that by erroring on replace directives you also take power away from module users (that have to wait for PR to be merged) and give it to module authors.

If a user needs to fork and send PRs for one or more modules, then this proposal is not for them. They can run go install (without a version) from their fork.

If you mean they need to wait for the author's PRs to be merged, they already have a problem with go get and all other commands, which ignore replace directives outside the main module.

The difference here is that go install pkg@version would report an error for replace instead of silently ignoring it.

If the new global install command becomes the community meme for installing programs then 10% of the existing modules are no longer installable.

Most (nearly all?) of these issues can be resolved by adjusting go.mod and tagging a new release.

We'll monitor this over time. If we need to change course, there are a couple ways we can do that, but as I've mentioned, we're starting with something strict so that those options are available to us without making a breaking change in the future.

I think in my discussion with @jayconrod I have provided some constructive feedback on how to improve this proposal by making the global install command respect replace directives. Let's say we take this proposal, remove everything that mentions the replace directive and instead say "the global install command is going to respect module replace directives, directory replaces can not be supported at the moment due to a limitation of goproxy which will be addressed in a future release" and explain how it plans to support directory replaces. I'd be ok with that.

You've suggested a large change to the current interpretation of replace directives, which would break lots of existing modules. You've also suggested a significant change to the proxy protocol, which would be expensive to implement across the ecosystem. These are significant drawbacks, and the benefits aren't at all clear to me. It would be difficult for such a proposal to be approved.

Those functions aren't incorrect, just not meant to be read by Gazelle.

Gazelle itself has directives in WORKSPACE for this.

In PR #2585, we started printing commands run by the builder binary any time there's a failure.

This tends to be pretty chatty in most circumstances. The command lines are useful for debugging the rules and the builder, but not for diagnosing problems in programs being built. These messages should not be shown by default, but there should be some way to opt into them.

Based on discussion in #2585, setting an environment variable like --action_env=GO_VERBOSE_FAILURES=1 seems like a good way to approach this.

This is #2621; did you mean a different PR?

Let's exclude the //tests directory and not make changes here. None of the .bzl files here should be imported by other repos, and almost nothing here follows Gazelle conventions.

Add comment and # keep (assuming this is the right reason):

# Don't list dependency on @bazel_tools//tools/build_defs/repo.bzl
deps = [], # keep

Same deal with # keep here.

In general, if there's any manual change that will get removed by another run of Gazelle, let's add a # keep to prevent that from happening.

@aarzilli

It wouldn't because it would behave the same, right?

No. When you run go install example.com/A/pkg from the module example.com/Main, it applies require and replace directives from example.com/Main, not example.com/A.

When you run go get example.com/A/pkg in module mode from outside any module, it silently ignores replace directives.

Many people expect that replace directives are applied in either or both cases, but there's no command that works that way.

When you run go install example.com/A/[email protected] (this proposal), it will report an error if the module example.com/A has replace directives. That way, there's no ambiguity.

What else would you be able to install besides a main package?

The main module is the module defined by the go.mod file in the current directory or a parent directory. It's likely different than the module providing the main package in this context.

Why is the current behavior of go get relevant when the impetus behind this change is that it is wrong?

go get is how executables are installed in module mode today, so that's the relevant thing to compare against. It's not wrong, just inconvenient and overloaded. If you want to install an executable globally in module mode, ignoring the module in the current directory, you have to do something like this:

$ (cd /; GO111MODULE=on go get example.com/A/pkg)

What about the main build command, go build?

go build applies replace directives from the module in the current directory, not from anywhere else. Same as go test, go run, go install, go list.

If their go.mod file is not considered how would this take away power from them?

If go install example.com/A/[email protected] applied replace directives from example.com/A, then the author of example.com/A might release a version that didn't build without replace directives.

If the module example.com/B depends on example.com/A, they are now broken unless they copy those replace directives, which may not even be feasible: the replacements from example.com/A might conflict with replacements from example.com/B.

By encouraging replace beyond development within one module, we take power away from module users and give it to module authors.

But you are breaking 10% of the ecosystem with this?

Who does this break? This doesn't change the interpretation of existing go install commands or any other command. It addresses a use case that wasn't adequately covered before.

If a module doesn't build without replace, then there's no build command that works outside that module.

If a module has replace but it can safely be ignored, then commands that work today will keep working (though we may deprecate go get for that purpose).

But why include replace at release versions if it's not needed? It only causes confusion.

I surveyed modules with main packages in "Appendix: usage of replace directives". I think the "soft fork" case is the only one we could realistically address, and that's 4% of modules.

My impression is that the intent was to obey the go.mod file in the current (or parent) directory. If that's not the case I don't think that section actually makes a case against applying the replace directives, if the replace directives of the current go.mod can't be applied then the replace directives of the tool being installed can be applied.

Covered above.

Nobody would do that and expect it to work. It also wouldn't work with git clone && go build which is what the global install command should match.

It sounds like the only advantage of this is that directory replace directives could be applied in modules that replace other modules in the same repository. That's less than 3% of modules with main packages. That's also a problem that's entirely within module authors' power to solve. They can tag releases for each module pointing to the same commit, then tag those commits.

But if you think this way I think you should propose a change to the documentation to say that replace directives shouldn't appear in published mod files ever. We could see what the community thinks about that rather than burying this change in the implementation of go install.

We're in the process of writing more module documentation. Usage of replace is one of topics we have planned and will likely advise caution around release versions.

@aarzilli

But it does. It's going to look at the go.mod file that's either in the current directory or in a parent directory and look up versions and replaces there.

No. The proposal says:

• go install runs in module mode, regardless of whether a go.mod file is present. If GO111MODULE=off, go install reports an error, similar to what go mod download and other module commands do.
• go install acts as if no go.mod file is present in the current directory or parent directory.
• No module will be considered the "main" module.

Ok, so why is this even mentioned in the proposal? Clearly tracking tool dependencies shouldn't influence the design of a global install command.

It's mentioned because it's a design constraint. In introducing a new feature, we don't want to change the ecosystem in a way that breaks existing usage.

The section "Why can't module replace directives be used?" discusses this: it includes an example similar to the one you gave earlier.

Yes. Current module zips are like this. But this doesn't work for a global install command, so a different type of archive needs to be added. ... Under what circumstances would [directory replacements] not work?

Any directory replacement outside the current repository. Any absolute path replacement.

Even if we could honor all replacements though, I don't think we should for the same reasons we're not honoring module replacements: if used widely, they prevent other modules from depending on modules that provide tools.

It's possible to define a build setting (like the flags in //go/config) that would do this, but build settings go into action cache keys, so using it would cause everything to be rebuilt.

I can confirm those <code> tags are generated by the Markdown renderer. Or at least: they're not in the original Markdown source.

@aarzilli

I believe to have refuted the points covered in the proposals, if you disagree with my rebuttal I would ask you to point the error in my way rather than simply stating that I am wrong.

I've referred you back to the design doc in a couple places where your points were covered already.

Other points about expected behavior I think are more of a matter of opinion. We've covered a lot of opinions, and this proposal is a compromise.

I think this is a bad idea that doesn't solve any problem and introduce new ones of its own.

You're not winning me over with this.

First off it is very strange, almost antithetical, that a global install command should have a behavior that depends on the current directory.

It doesn't depend on the current directory. That's the point. If you want to install an executable without modifying the go.mod file in the current directory or changing to another directory, you don't have to change to another directory anymore.

Secondly, let's make an example. Let's say I'm building a module that needs a code generator, let's call it goblah. ...

You wouldn't use the new functionality in this situation. You would use it to install tools that aren't specifically related to any project like gopls or goimports.

Your example mostly works today, and we're trying to keep it working by not encouraging widespread use of replace.

You can use go run to avoid installing an executable directly:

//go:generate go run example.com/tool

Or in a script with non-global go install:

#!/bin/bash

GOBIN=bin go install example.com/tool1 example.com/tool2 # versions come from our go.mod
bin/tool1
bin/tool2

Or with go build:

#!/bin/bash

go build -o bin/ example.com/tool1 example.com/tool2 # versions come from our go.mod
bin/tool1
bin/tool2

These commands work consistently. They use go.mod in the current module to select versions.

What's really needed here is a command that will download an external tool, build it as specified in the go.mod file and execute it. Let's call this command go mod execute-ext-tool, then the go:generate directive could be changed to:

You're describing go run. It works today, though it's a little slow because we don't cache the linked binary. We can improve that.

This proposal is not meant to address that use case.

That's not what I'm suggesting. I'm suggesting that whatever is implemente should behave as if git clone && go build almost 100% of the time. For example go-global-install could request a special version to goproxy, in this format: github.com/blahworld/goblah@main:v31.0.0, then goproxy would know to prepare and serve an archive of the working directory retrieved from the repository at version 31.0.0. This archive could be checksummed in a similar way and wouldn't conflict with [email protected] due to being in a different namespace.

The important difference is that a module zip file contains files from one module, not from other modules in the same repository. Directory replace directives always point outside the current module, most commonly to other modules in the same repository, but sometimes to completely different repositories. That's why we can't honor them.

Even if we packed all modules into a single zip file as you're suggesting, we couldn't make directory replacements work all the time.

I disagree. They do no such thing on an executable, you can have as many incompatible replace directives as you want on different executables without any interoperability problems. And if this is the belief of the go team then the documentation of replace should be changed to reflect that.

Part of the rationale of this proposal is that you should be able to install an executable either within a dependent module (applying the constraints and replace directives from that module) or globally (without a main module). The former case is important for tools like code generators or analyzers that might be needed at specific versions or with modifications.

If we honor replace directives in the latter case, module authors will rely more heavily on replace directives, making the former case non-viable. I don't think that's an acceptable tradeoff when we can serve both cases.

We also can't honor directory replace directives at all. When something is downloaded into the module cache, relative and absolute systems from another repository aren't meaningful. Honoring some replace directives but not others adds too much complication.

One more point about downloading from VCS directly: if we completely step outside the module system for downloading code (which is what's being suggested), not only is it much slower (typically 5-7x, even with --depth=1), you're also throwing out safety: there's no go.sum file, so without the checksum database, you have no guarantee that the repository sends you the same bits as anyone else.

Sure, it sounds like we're in agreement this is a good idea.

Does anyone on the release team have bandwidth to fix this for 1.16? I'm not familiar with the installers, and I'm not sure if I'll have bandwidth to look at this before the freeze.

I tend to agree this is a bit too chatty. @linzhp WDYT?

I don't think Bazel communicates the --verbose_failures flag to Starlark rules or actions, so we can't really do anything with that. Since this output is mainly useful for debugging the rules and the builder, how about something like --action_env=GO_VERBOSE_FAILURES=1? The builder could just check for that environment variable.

Is it too late to roll back the whole "global install command" thing completely?

This proposal hasn't been formally accepted yet. However, I think there's a pretty firm consensus to move forward with this in 1.16. The lack of a global install command has been a significant usability problem, and many people have asked for something that solves this problem.

But at this point we've lived without it for 2 years, READMEs have been changed, the community has adapted, do we still need it?

I don't think the community has adapted. Many instructions I've seen recommend changing to a directory outside a module, then running go get in either GOPATH mode or with an explicit GO111MODULE=on. I think we need a more convenient, consistent way of installing tools.

And if it isn't going to do ~100% the same thing as git clone && go build is it a net good or a net negative?

In module mode, this would be unexpected behavior. The go command usually fetches dependencies from a proxy. Even in direct mode, it doesn't fetch a whole repository. This is discussed in the design doc.

A side effect of the way it's being implemented is that it discourages applications from using replace directives, heavily, if it gets adopted by the community as the default way to install applications. It's strange that replace directives are in the language but the tooling discourages from using them. If this is the design we settle in then replace directives should get a deprecation warning in the documentation.

replace is not deprecated, and there's no issue with using it during development.

replace is discouraged in release versions that other modules may depend on. replace directives are only applied in the main module; they're ignored by go install and go get in another module or outside modules. This leads to subtle differences in selected versions depending on what command was issued where. We felt that reporting an error was preferable to that ambiguity.

This is also discussed in the design doc and at length in the previous discussion in #30515.

How can I put many different libraries into on GoArchive/Target?

You can't. I was just thinking that if you only had one importable package, no change would be needed.

I think this ought to be possible though. I'll add a note to #2578. If there's a substantial change to the API in the future, that ought to be included.

For the short term, documenting that in go.library_to_source, attr["deps"] could contain Targets or GoArchives seems like the best way to resolve this.

Update boilerplate for v0.22.1; update to rules_go v0.24.3

Announce releases 0.24.3, 0.23.11 [skip ci]

Update boilerplate for v0.22.1; update to rules_go v0.24.3

Announce releases 0.24.3, 0.23.11 [skip ci]

This should be unblocked by #2658.

CLA verified manually.

tests: upgrade gazelle to v0.22.0

tests: upgrade gazelle to v0.22.0

What type of PR is this?

Bug fix

What package or component does this PR mostly affect?

language/go gazelle update-repos

What does this PR do? Why is it needed?

Allow update-repos to operate in-place rather than through a temp copy. Previously, any go.mod files containing relative on-disk replace directives would completely break update-repos, since the temp copy's relative paths would all be broken.

Which issues(s) does this PR fix?

Fixes #650

What version of gazelle are you using?

0.18.1

What version of rules_go are you using?

0.19.0

What version of Bazel are you using?

0.28.1

Does this issue reproduce with the latest releases of all the above?

I believe so.

What operating system and processor architecture are you using?

macOS / x64

What did you do?

With a go.mod file like the following:

module github.com/foo/bar

go 1.12

require (
	baz.com v0.0.0
)

replace baz.com => ./build-support/baz

What did you expect to see?

I was hoping to see the same behavior as I do with absolute paths. Namely:

gazelle: go_repository does not support file path replacements for compass.com -> /Users/cwaeland/development/foo/build-support/baz

What did you see instead?

I get the following output:

go: parsing build-support/baz/go.mod: open /private/var/folders/s6/tpqlfq494czcv34zgzwm4vy40000gp/T/gazelle-temp-gomod900090332/build-support/baz/go.mod: no such file or directory
go: error loading module requirements
gazelle: error parsing "go.mod": exit status 1

I thought this would have been covered by https://github.com/bazelbuild/bazel-gazelle/issues/407 but it doesn't seem to be.

What type of PR is this?

Bug fix

What does this PR do? Why is it needed? go tool compile writes syntax errors to stdout, including the one reported in #2592. Meanwhile, all regular output of subcommands should have been written to files. We should direct all stdout of subcommands to stderr, so we can find all errors in stderr. This mirrors behavior in the go command

# keep comments can be applied at multiple levels of the syntax tree. A comment after an attribute only prevents that attribute from being modified, but the whole repository declaration could still be deleted.

To preserve the whole declaration, it needs to go above like this:

# keep
go_repository(
    name = "org_golang_x_mod",
    importpath = "golang.org/x/mod",
    sum = "h1:RM4zey1++hCTbCVQfnWeKs9/IEsaBLA8vTkd0WVtmH4=",
    version = "v0.3.0",
)

@abursavich There are a couple significant problems with that approach. It would be a break from current go install behavior, and it would be inconsistent with other build commands (go build, go run, and so on).

It is confusing that there will be two variants of go install, but instead of changing the semantics of go install pkg, I think the best way to resolve that would be to remove go install pkg and only allow go install pkg@version. That seems like too disruptive of a change to me, but I'm curious to hear other opinions.

build_naming_convention was misaligned.

build_naming_convention was misaligned.

Fixes #903

<!-- Please answer these questions before submitting your issue. Thanks! -->

What version of gazelle are you using?

v0.22.0

<!-- Check bazel_gazelle in WORKSPACE if you're not sure -->

What version of rules_go are you using?

v0.24.1

<!-- Check io_bazel_rules_go in WORKSPACE if you're not sure -->

What version of Bazel are you using?

v3.3.1 (but on v3.5.0 also reproduced)

<!-- Run "bazel version" to find out -->

Does this issue reproduce with the latest releases of all the above?

I only tried on the latest release.

What operating system and processor architecture are you using?

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.1 LTS
Release:        20.04
Codename:       focal

$ uname -a
Linux asmirnov 5.4.0-40-generic #44-Ubuntu SMP Tue Jun 23 00:01:04 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

What did you do?

<!-- If possible, provide a minimal recipe for reproducing the error. -->

repro repo: https://github.com/asv/rules_go_cycle_bug

$ bazel build //pkg/pubsub/...

What did you expect to see?

A successfully completed build command.

What did you see instead?

$ bazel build //pkg/pubsub/...
ERROR: /home/asmirnov/.cache/bazel/_bazel_asmirnov/7dba41bc404cf3230b6d76cff81a3467/external/com_github_nats_io_stan_go/BUILD.bazel:3:11: in go_library rule @com_github_nats_io_stan_go//:stan.go: cycle in dependency graph:
    //pkg/pubsub:go_default_library
    @com_github_nats_io_stan_go//:go_default_library
.-> @com_github_nats_io_stan_go//:stan.go [self-edge]
`--
This cycle occurred because of a configuration option
ERROR: Analysis of target '//pkg/pubsub:go_default_library' failed; build aborted
INFO: Elapsed time: 0.149s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (1 packages loaded, 2 targets configured)

Fixes #903

This lets arguments contain newlines.

Fixes #2635

What version of rules_go are you using?

v0.24.0

What version of gazelle are you using?

n/a

What version of Bazel are you using?

3.4.1

Does this issue reproduce with the latest releases of all the above?

yes

What operating system and processor architecture are you using?

Darwin / amd64

Any other potentially useful information about your toolchain?

n/a

What did you do?

Build a target with a package conflict error, as in #2633.

What did you expect to see?

Complete package conflict error with labels of targets causing the conflict.

What did you see instead?

Everything after the first line is truncated.

package conflict error: github.com/golang/protobuf/protoc-gen-go/descriptor: multiple copies of package passed to linker:
bazel: Leaving directory `/private/var/tmp/_bazel_jayconrod/0469643e52a025b5c8b5346853bd7ba4/execroot/__main__/'

The error is passed in a .params file:

-conflict_err
package conflict error: github.com/golang/protobuf/protoc-gen-go/descriptor: multiple copies of package passed to linker:
	@com_github_golang_protobuf//protoc-gen-go/descriptor:descriptor
	@io_bazel_rules_go//proto/wkt:descriptor_go_proto
Set "importmap" to different paths or use 'bazel cquery' to ensure only one
package with this path is linked.

rules_go uses the multiline params file format, so we expect one argument per line. Arguments with newlines are interpreted as multiple arguments.

We should use she shell format instead and support unquoting when reading params files.

I'd like to guide this issue to some resolution. I don't think we really know what went wrong. Having the -x log would help.

This doesn't seem related to whether the host contains a non-routable address or not. We don't allow module paths that don't have a dot in the first path element (see Module paths and versions, but local names and IP addresses are fine.

Finding a repository for a module path describes the process. That section doesn't cover qualified module paths, so it should definitely be updated.

When the module path ends with a VCS qualifier like .git, the go command will derive a repository URL directly from that path instead of sending a ?go-get=1 request. It doesn't know the scheme, so it tries git, https, http, git+ssh, and ssh (git and http are only allowed if GOINSECURE matches).

I believe everything above this line is printed by Bazel:

compilepkg: error running the following subcommand: exit status 2

Maybe open this issue in bazelbuild/build? I'm pretty sure rules_go doesn't have control over the duplicate part here.

Instead of changing this file, let's change env.runCommand.

Add a comment that this mirrors behavior in the go command: https://go.googlesource.com/go/+/refs/tags/go1.15.2/src/cmd/go/internal/work/exec.go#1958

https://build.golang.org/log/f6f8b321bc4fbcc3948d26f6ed009e682f98cc8f

Broken by CL 255052. Looks like the test just needs a go.mod file.

update-repos only mutates the file passed to -to_macro, while the pruning applies to all the files added via a # gazelle:repository_macro comment. One issue is that it is inconsistent/surprising, but the biggest issue to me is that this is no a behaviour a user would want in the first place.

This might be the source of confusion: -to_macro tells Gazelle to add new declarations to that macro, but Gazelle may still update existing declarations in WORKSPACE or in other macros. The expectation is that all macros declared with # gazelle:repository_macro are managed by Gazelle.

Gazelle won't update or delete declarations that have a # keep comment. I don't think that's currently supported for entire macros, but it might be a reasonable thing to add. Maybe that would solve your problem.

I should be able to get to this in a couple days. I was sprinting to get CL 255052 and its prerequisite features merged. Now that it's done, I should have time to work on more things.

If the *_repositories function is declared in the main workspace, you can declare it with a directive:

# gazelle:repository_macro repositories.bzl%repositories

Otherwise, Gazelle can't see it, so the individual dependencies can be declared instead. This is also needed for dependencies declared with something other than go_repository:

# gazelle:repository go_repository name=com_example_repo importpath=example.com/repo

That's possible, but I think it's better to have an explicit declaration. Otherwise, it's too easy to assume that .bzl files in other workspaces are allowed.

The only open question to me here is whether Gazelle should perform external dependency resolution at all. Maybe it should just be an error to import a package from a module that isn't declared. #499 proposes something like that (mainly for go_repository).

This seems like a pretty specialized situation; I'm not really convinced -prune should change. If I remove a dependency, I'd like -prune to remove it and its dependencies from whichever macros they're declared in.

There's a deeper issue of course: the use of semantic versioning in Go modules assumes that module developers always know when they break backwards compatibility and need to tag a new major version. This assumption is obviously and demonstrably false (obligatory XKCD: https://xkcd.com/1172/) but this has already been widely discussed.

@twpayne go release is meant to help with that. There's an experimental version at golang.org/x/exp/cmd/gorelease.

If an author finds that they have unintentionally broken backward compatibility, one option is to revert the change, tag a new release, and retract releases containing the change (#24031).

@abursavich

Thanks for the feedback on this issue. We know this is an incompatible change to the CLI. We're trying not to cause any more disruption than necessary, but we think it's more important in the long term to get the default behavior right.

I understand the reason for this change and the behavior of the go tool is well documented in tip. However, as a longtime go user running tests against tip, minimally sophisticated enough to find the breaking change in the go tool, I'm here to tell you it's not intuitive that using go install to install a command would ever edit the go.mod. When I want to install a command, I don't want to depend on its module. I would use go get for that.

In module mode (and arguably in GOPATH mode, too), go install and go get have had a lot of overlap. We'd like to distinguish them further: go install may eventually just be used for installing executables. go get may just be used for managing dependencies in go.mod.

Side note: Appending a version to switch to "global" mode isn't intuitive or consistent with other go commands either.

In short, we're trying to address two use cases with go install in module mode: installing executables in the context of the current module, and installing executables without regard for the current module (if there even is one).

Installing tools from the current module is an important use case. In fact, it's one I'd recommend in CI. You could add a requirement for some minimum version of the tool's module, then go install that. If you don't want to keep tool requirements in go.mod, you could put them in another .mod file specified with -modfile.

Of course that's not always desirable, so there needs to be a way to install tools regardless of the current module. #40276 is the main issue for that. There's been extensive discussion (and previously in #30515), so if you feel that this should work differently, please comment there.

I think install should not modify go.mod and it should fallback to the network. If trying to install a command not in the current module, go install package should behave the same as go install package@latest. This would make it symmetric with the familiar behavior of get.

This would make go install too unpredictable. What if some dependencies are in go.mod but not others? We want module commands to be repeatable: the set of versions they use should either 1) come from go.mod, 2) should be written to go.mod if something new is needed, or 3) the command line should indicate that it's not repeatable (e.g., @latest).

Gazelle won't evaluate Starlark code or invoke Bazel. Both are firmly out of scope.

If there are multiple macros, you can have multiple declarations. They all have to be in the main workspace though, since loading files from other workspaces would require running Bazel.