profile
viewpoint

bazelbuild/bazel 15426

a fast, scalable, multi-language and extensible build system

google/skylark 1157

Skylark in Go: the Skylark configuration language, implemented in Go [MOVED to go.starlark.net]

google/starlark-go 1068

Starlark in Go: the Starlark configuration language, implemented in Go

bazelbuild/bazel-gazelle 481

Gazelle is a Bazel build file generator for Bazel projects. It natively supports Go and protobuf, and it may be extended to support new languages and custom rule sets.

jayconrod/gypsum 51

An experimental new programming language

bazelbuild/bazel-integration-testing 25

Framework for integration tests that call Bazel

jayconrod/rules_go_simple 23

A simple set of Go rules for Bazel, used for learning and experimentation.

jayconrod/imp-interpreter 9

A minimal interpreter for the toy language, IMP, used as an example for building interpreters.

jayconrod/minibox 4

Tiny experimental program for running tiny experimental containers

jayconrod/pinky-mode 4

An Emacs minor mode which lets you navigate without holding Control. Save your pinkies!

issue commentgolang/go

proposal: cmd/go: 'go install' should install executables in module mode outside a module

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.

jayconrod

comment created time in 3 days

issue commentgolang/go

proposal: cmd/go: 'go install' should install executables in module mode outside a module

@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?

jayconrod

comment created time in 3 days

issue commentgolang/go

proposal: cmd/go: 'go install' should install executables in module mode outside a module

@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:

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.

jayconrod

comment created time in 3 days

issue commentbazelbuild/bazel-gazelle

language/go: improve dependency resolution docs; maybe exit non-zero on failure

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

Gazelle itself has directives in WORKSPACE for this.

uhthomas

comment created time in 3 days

issue openedbazelbuild/rules_go

go: make error output less verbose

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.

created time in 3 days

Pull request review commentbazelbuild/rules_go

Create bzl_library entries using gazelle-skylark

+load("@bazel_skylib//:bzl_library.bzl", "bzl_library")

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

achew22

comment created time in 4 days

Pull request review commentbazelbuild/rules_go

Create bzl_library entries using gazelle-skylark

+load("@bazel_skylib//:bzl_library.bzl", "bzl_library")

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.

achew22

comment created time in 4 days

Pull request review commentbazelbuild/rules_go

Create bzl_library entries using gazelle-skylark

 filegroup(     srcs = glob(["**"]),     visibility = ["//visibility:public"], )++bzl_library(+    name = "bindata",+    srcs = ["bindata.bzl"],+    visibility = ["//visibility:public"],+    deps = [+        "@io_bazel_rules_go//go:def",+        "@io_bazel_rules_go//go/private/rules:rule",+    ],+)++bzl_library(+    name = "embed_data",+    srcs = ["embed_data.bzl"],+    visibility = ["//visibility:public"],+    deps = [+        "@io_bazel_rules_go//go/private:context",+        "@io_bazel_rules_go//go/private/rules:rule",+    ],+)++bzl_library(+    name = "embed_data_deps",+    srcs = ["embed_data_deps.bzl"],+    visibility = ["//visibility:public"],+    deps = [+        #"@bazel_tools//tools/build_defs/repo:git",

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

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

comment created time in 4 days

Pull request review commentbazelbuild/rules_go

Create bzl_library entries using gazelle-skylark

 config_setting(     name = "stamp",     values = {"stamp": "true"}, )++bzl_library(+    name = "context",+    srcs = ["context.bzl"],+    visibility = [+        "//extras:__pkg__",+        "//go:__subpackages__",+    ],+    deps = [

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.

achew22

comment created time in 4 days

PullRequestReviewEvent
PullRequestReviewEvent

issue commentgolang/go

proposal: cmd/go: 'go install' should install executables in module mode outside a module

@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/pkg@v1.0.0 (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/pkg@v1.0.0 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.

jayconrod

comment created time in 4 days

issue commentgolang/go

proposal: cmd/go: 'go install' should install executables in module mode outside a module

@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.

jayconrod

comment created time in 4 days

pull request commentbazelbuild/rules_go

Print out subcommand when it fails

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.

linzhp

comment created time in 4 days

issue commentgolang/go

x/website: spaces in preformatted blocks (as rendered from Markdown) are unintentionally collapsed

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

bupjae

comment created time in 4 days

issue commentgolang/go

proposal: cmd/go: 'go install' should install executables in module mode outside a module

@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 goblah@v31.0.0 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.

jayconrod

comment created time in 4 days

issue commentgolang/go

proposal: cmd/go: 'go install' should install executables in module mode outside a module

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.

jayconrod

comment created time in 4 days

issue commentgolang/go

x/build/cmd/release: installers should add GOBIN to PATH

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.

jayconrod

comment created time in 4 days

pull request commentbazelbuild/rules_go

Print out subcommand when it fails

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.

linzhp

comment created time in 4 days

issue commentgolang/go

proposal: cmd/go: 'go install' should install executables in module mode outside a module

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.

jayconrod

comment created time in 4 days

issue commentbazelbuild/rules_go

go.library_to_source should only accept Targets for deps

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.

jayconrod

comment created time in 4 days

delete branch jayconrod/bazel-gazelle

delete branch : update

delete time in 6 days

push eventbazelbuild/bazel-gazelle

Jay Conrod

commit sha 2f9261b27f1d2660e2952bc9a0e79e4e81691afe

Update boilerplate for v0.22.1; update to rules_go v0.24.3 (#915)

view details

push time in 6 days

PR merged bazelbuild/bazel-gazelle

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

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

+9 -9

0 comment

2 changed files

jayconrod

pr closed time in 6 days

delete branch jayconrod/rules_go

delete branch : announce-release

delete time in 6 days

push eventbazelbuild/rules_go

Jay Conrod

commit sha 64bfa14993c7841aaefbbe1f1aecaad72f302974

Announce releases 0.24.3, 0.23.11 [skip ci] (#2659)

view details

push time in 6 days

PR merged bazelbuild/rules_go

Announce releases 0.24.3, 0.23.11 [skip ci] cla: yes

Announce releases 0.24.3, 0.23.11 [skip ci]

+23 -22

0 comment

1 changed file

jayconrod

pr closed time in 6 days

created tagbazelbuild/bazel-gazelle

tagv0.22.1

Gazelle is a Bazel build file generator for Bazel projects. It natively supports Go and protobuf, and it may be extended to support new languages and custom rule sets.

created time in 6 days

release bazelbuild/bazel-gazelle

v0.22.1

released time in 6 days

created tagbazelbuild/rules_go

tagv0.24.3

Go rules for Bazel

created time in 6 days

release bazelbuild/rules_go

v0.24.3

released time in 6 days

created tagbazelbuild/rules_go

tagv0.23.11

Go rules for Bazel

created time in 6 days

release bazelbuild/rules_go

v0.23.11

released time in 6 days

PR opened bazelbuild/bazel-gazelle

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

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

+9 -9

0 comment

2 changed files

pr created time in 6 days

create barnchjayconrod/bazel-gazelle

branch : update

created branch time in 6 days

PR opened bazelbuild/rules_go

Announce releases 0.24.3, 0.23.11 [skip ci]

Announce releases 0.24.3, 0.23.11 [skip ci]

+23 -22

0 comment

1 changed file

pr created time in 6 days

create barnchjayconrod/rules_go

branch : announce-release

created branch time in 6 days

push eventbazelbuild/bazel-gazelle

Jay Conrod

commit sha da7c1edeed5503825eb4b2c9dd17db955f36c4d2

language/go: partial cherry-pick of runGoCommandForOutput From #911

view details

Scott Blum

commit sha 6429ae57eca2444f0aea936fa302e0e8128bc0a9

update-repos can work with a go.mod file in place (#912) 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. Fixes #650

view details

push time in 6 days

push eventbazelbuild/bazel-gazelle

Jay Conrod

commit sha 5d9cf0c87b6ac358503bfd9c362053bd3f318ef7

all: exclude .idea in root directory (#901) Fixes #894

view details

Jay Conrod

commit sha f36de174dbb008f74bc311c7bc9c36afaa6ba6a5

language/go: infer rules_go version from WORKSPACE (#905) We prefer to read RULES_GO_VERSION from @io_bazel_rules_go//go:def.bzl, but that won't be available if the bazel-out symlink hasn't been created yet. As a fallback, look for the io_bazel_rules_go declaration in WORKSPACE, and try to extract the version from the URLS. Fixes #780

view details

Jay Conrod

commit sha 270fe58ebba718bc9a52fdc88fb3189f48aca00f

gazelle_binary: add extra _stdlib attr for older rules_go versions (#906) Before rules_go v0.23.0, rules were required to have an _stdlib attribute, which was usually provided via the go_rules wrapper. Now, that dependency comes from _go_context_data. Adding an extra edge keeps us compatible with older versions. Fixes #896

view details

Jay Conrod

commit sha fe5055c8d9df9dfb35b3ff3fa8428460c12f9459

language/go: replace dots with underscores in generated names (#913) Fixes #903

view details

push time in 6 days

push eventbazelbuild/rules_go

Jay Conrod

commit sha fc2921132f0f672e55d16903ea37194da1b6eac3

go_test: pass cdeps files to linker after split test recompilation (#2625) When a test contains both internal and external files, and the external files indirectly import the library under test, some package need to be recompiled so that the packages that import the library under test are compiled with the internal test archive instead. This was implemented in #2579. That change caused a regression: the recompiled archives didn't include input files from cdeps dependencies. This change adds a new GoArchiveData field to track direct dependencies. That can be used to rebuild a depset of all the needed files. Fixes #2622

view details

Jay Conrod

commit sha ba5d09d9cd2ecd76d3fe2af3c2003302f16f1c0b

go: add comment on why external linking is needed (#2630) For #2614

view details

Jannis Andrija Schnitzer

commit sha 89626322d125b838b14cd7f36229848ba00f1b53

Use absolute paths in GoPath builder (mainly for Windows compatibility) (#2642) Windows has a limit of 256 characters for relative characters when using the syscalls the Go standard library uses. In a Bazel project I encountered recently I couldn't run the GoPath builder because of an google.golang.org/grpc dependency that included the file bazel-out\x64_windows-fastbuild\bin\external\org_golang_google_grpc\reflection\grpc_reflection_v1alpha\grpc_reflection_v1alpha_go_proto_\google.golang.org\grpc\reflection\grpc_reflection_v1alpha\reflection.pb.go, which even with my very short bazel root of C:\tmp\bzl was too long to open, and resulted in the error message GoPath: open bazel-out\x64_windows-fastbuild\bin\external\org_golang_google_grpc\reflection\grpc_reflection_v1alpha\grpc_reflection_v1alpha_go_proto_\google.golang.org\grpc\reflection\grpc_reflection_v1alpha\reflection.pb.go: The system cannot find the path specified. (pasting verbatim so people googling it can find it) Using abs() and FromSlash() like in other builders fixes this issue.

view details

Chris K

commit sha 634d3ddcbc60a393d86db4ae7116022181ee36ab

Fix positional argument (#2651) When I copy and paste this line, I get Error in label: label() got unexpected positional argument from bazel.

view details

Andrew Tarashkevich

commit sha 65907726162e16fedc528c4e1fd40b26186729f2

Export zoneinfo from go sdk. (#2596) To run the CockroachDB node, you need to [provide an archive of time zones from your environment](https://www.cockroachlabs.com/docs/v20.1/known-limitations.html#location-based-time-zone -names). And when using Bazel, it would be very convenient to use this `zoneinfo.zip` from the sdk provided by the role_go.

view details

Jay Conrod

commit sha 29162fccd921df39bafab2f130db7d5623b9d345

go: use "shell" params file format instead of "multiline" (#2655) This lets arguments contain newlines. Fixes #2635

view details

Zhongpeng Lin

commit sha 6ac117ca287b9172994538204fe66c2d42bfafa4

Redirecting all stdout of subcommands to stderr (#2656) 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

view details

push time in 6 days

push eventbazelbuild/rules_go

Jay Conrod

commit sha 2fe683b16c256adceac263a4ea235a8211368b1a

Set RULES_GO_VERSION to 0.24.3

view details

Jannis Andrija Schnitzer

commit sha 7206d154b36ff3c83b1a14debfffb8c0bd60fcbb

Use absolute paths in GoPath builder (mainly for Windows compatibility) (#2642) Windows has a limit of 256 characters for relative characters when using the syscalls the Go standard library uses. In a Bazel project I encountered recently I couldn't run the GoPath builder because of an google.golang.org/grpc dependency that included the file bazel-out\x64_windows-fastbuild\bin\external\org_golang_google_grpc\reflection\grpc_reflection_v1alpha\grpc_reflection_v1alpha_go_proto_\google.golang.org\grpc\reflection\grpc_reflection_v1alpha\reflection.pb.go, which even with my very short bazel root of C:\tmp\bzl was too long to open, and resulted in the error message GoPath: open bazel-out\x64_windows-fastbuild\bin\external\org_golang_google_grpc\reflection\grpc_reflection_v1alpha\grpc_reflection_v1alpha_go_proto_\google.golang.org\grpc\reflection\grpc_reflection_v1alpha\reflection.pb.go: The system cannot find the path specified. (pasting verbatim so people googling it can find it) Using abs() and FromSlash() like in other builders fixes this issue.

view details

Zhongpeng Lin

commit sha 977f05cd52de7b63384598143ff4f40261973316

Reusing workDir to store nogo facts and export data (#2648)

view details

Chris K

commit sha 00707b7400c8dfd2e689852b6f580f7687aeef50

Fix positional argument (#2651) When I copy and paste this line, I get Error in label: label() got unexpected positional argument from bazel.

view details

Chris K

commit sha 69b965e5c67b1a68ad713f149b4825716a258715

archive: use library's name for archive name (#2652) If a custom Go rule generates more than one library, or otherwise changes the name of the GoLibrary, the emitted archive will still have the _ctx.label.name. To deconflict, use the library's name as the emitted archive's name. Signed-off-by: Chris Koch <chrisko@google.com>

view details

Andrew Tarashkevich

commit sha 3d680bdcc104d46dfaf62710e09ab0f5c4618c36

Export zoneinfo from go sdk. (#2596) To run the CockroachDB node, you need to [provide an archive of time zones from your environment](https://www.cockroachlabs.com/docs/v20.1/known-limitations.html#location-based-time-zone -names). And when using Bazel, it would be very convenient to use this `zoneinfo.zip` from the sdk provided by the role_go.

view details

Jay Conrod

commit sha fab357364a87e81fc53371500d8a419beadb4324

go: use "shell" params file format instead of "multiline" (#2655) This lets arguments contain newlines. Fixes #2635

view details

Zhongpeng Lin

commit sha e04f57320564a7a178e24322eb85a51ee6c530df

Redirecting all stdout of subcommands to stderr (#2656) 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

view details

push time in 6 days

push eventbazelbuild/rules_go

Jay Conrod

commit sha 64d81e8b75c0457427ecab911e0ee2ab8d13c9e7

Set RULES_GO_VERSION to 0.23.11

view details

Zhongpeng Lin

commit sha 0c414cdd0f9f37bd6a39a1434fd7baafc3e598e0

Print out subcommand when it fails (#2585) --verbose_failures only prints out the command that Bazel rules call directly. If a binary calls several subcommands (e.g., compilepkg), we don't know which subcommand fails until we run the parent command manually. For failures that cannot be reproduced locally (e.g., the Windows errors of #2461), printing out the subcommand gives us better idea what could have gone wrong.

view details

Zhongpeng Lin

commit sha 10b8843b2af2adf40ab029f343366b5d38112ff9

Setting comment position according to inserted import (#2602) * Copied the implementation of AddNamedImport from golang.org/x/tools/go/ast/astutil to better handle comments. * Added integration test to verify the fix. Fixes #2592

view details

Jay Conrod

commit sha 592523d8c04927c73cfe110057923e96b48ef4b8

Update bazel_toolchains in WORKSPACE (#2624)

view details

Jay Conrod

commit sha 05d0fee8a2424b5bf25695b87a1d2a0458f1ca60

Drop exclusions for removed tests (#2626)

view details

Jay Conrod

commit sha 50525abdf3217c239e23958c53b8544b97e24723

go_test: pass cdeps files to linker after split test recompilation (#2625) When a test contains both internal and external files, and the external files indirectly import the library under test, some package need to be recompiled so that the packages that import the library under test are compiled with the internal test archive instead. This was implemented in #2579. That change caused a regression: the recompiled archives didn't include input files from cdeps dependencies. This change adds a new GoArchiveData field to track direct dependencies. That can be used to rebuild a depset of all the needed files. Fixes #2622

view details

Jay Conrod

commit sha 2f19c8da0ccf28dc5b5a7812988f88502703947d

go: add comment on why external linking is needed (#2630) For #2614

view details

Jannis Andrija Schnitzer

commit sha c64207420bfbac2dd4bded5f31be96558e52fe40

Use absolute paths in GoPath builder (mainly for Windows compatibility) (#2642) Windows has a limit of 256 characters for relative characters when using the syscalls the Go standard library uses. In a Bazel project I encountered recently I couldn't run the GoPath builder because of an google.golang.org/grpc dependency that included the file bazel-out\x64_windows-fastbuild\bin\external\org_golang_google_grpc\reflection\grpc_reflection_v1alpha\grpc_reflection_v1alpha_go_proto_\google.golang.org\grpc\reflection\grpc_reflection_v1alpha\reflection.pb.go, which even with my very short bazel root of C:\tmp\bzl was too long to open, and resulted in the error message GoPath: open bazel-out\x64_windows-fastbuild\bin\external\org_golang_google_grpc\reflection\grpc_reflection_v1alpha\grpc_reflection_v1alpha_go_proto_\google.golang.org\grpc\reflection\grpc_reflection_v1alpha\reflection.pb.go: The system cannot find the path specified. (pasting verbatim so people googling it can find it) Using abs() and FromSlash() like in other builders fixes this issue.

view details

Chris K

commit sha 7047d5030cc3338a44c8dab9a6e11a60b2b16f8a

Fix positional argument (#2651) When I copy and paste this line, I get Error in label: label() got unexpected positional argument from bazel.

view details

Andrew Tarashkevich

commit sha 2b1d8afae50ee4df468aee95046b956bb258cef1

Export zoneinfo from go sdk. (#2596) To run the CockroachDB node, you need to [provide an archive of time zones from your environment](https://www.cockroachlabs.com/docs/v20.1/known-limitations.html#location-based-time-zone -names). And when using Bazel, it would be very convenient to use this `zoneinfo.zip` from the sdk provided by the role_go.

view details

Jay Conrod

commit sha 31952f424f31aed359b91cc88342704164d6e2da

go: use "shell" params file format instead of "multiline" (#2655) This lets arguments contain newlines. Fixes #2635

view details

Zhongpeng Lin

commit sha 27dc0d9449e8bd82cc997c098056a6530f959e36

Redirecting all stdout of subcommands to stderr (#2656) 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

view details

push time in 6 days

pull request commentbazelbuild/rules_go

Create bzl_library entries using gazelle-skylark

This should be unblocked by #2658.

CLA verified manually.

achew22

comment created time in 6 days

delete branch jayconrod/rules_go

delete branch : update-gazelle

delete time in 6 days

push eventbazelbuild/rules_go

Jay Conrod

commit sha d144b0068854d29e10bc727a0cecaf14ebb74c5e

tests: upgrade gazelle to v0.22.0 (#2658)

view details

push time in 6 days

PR merged bazelbuild/rules_go

tests: upgrade gazelle to v0.22.0 cla: yes

tests: upgrade gazelle to v0.22.0

+269 -270

0 comment

6 changed files

jayconrod

pr closed time in 6 days

delete branch jayconrod/rules_go

delete branch : test

delete time in 6 days

PR opened bazelbuild/rules_go

tests: upgrade gazelle to v0.22.0

tests: upgrade gazelle to v0.22.0

+269 -270

0 comment

6 changed files

pr created time in 6 days

create barnchjayconrod/rules_go

branch : test

created branch time in 6 days

delete branch jayconrod/misc

delete branch : pr

delete time in 6 days

push eventjayconrod/misc

Jay Conrod

commit sha 7432ef1eb521ce11caa2676b9c27a40aff48ed87

pr

view details

Jay Conrod

commit sha 8cb0b4f2fbb4afabd702c54a07441448299382c8

Merge pull request #1 from jayconrod/pr pr

view details

push time in 6 days

PR merged jayconrod/misc

pr
+1 -1

0 comment

1 changed file

jayconrod

pr closed time in 6 days

PR opened jayconrod/misc

pr
+1 -1

0 comment

1 changed file

pr created time in 6 days

create barnchjayconrod/misc

branch : pr

created branch time in 6 days

create barnchjayconrod/rules_go

branch : update-gazelle

created branch time in 6 days

delete branch jayconrod/rules_go

delete branch : update-gazelle

delete time in 6 days

push eventjayconrod/rules_go

Jay Conrod

commit sha 20b9bf5e10b3d432797e91101c8b0296aa36e2ad

tests: upgrade gazelle to v0.22.0

view details

push time in 6 days

create barnchjayconrod/rules_go

branch : update

created branch time in 6 days

push eventjayconrod/rules_go

Jay Conrod

commit sha d3e3b930a6964cd0073f13b170fe5043a74005a1

tests: upgrade gazelle to v0.22.0

view details

push time in 6 days

push eventbazelbuild/bazel-gazelle

Scott Blum

commit sha 9dd15db70e61d5f34ba360e10c7acdb81555b11f

update-repos can work with a go.mod file in place (#912) 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. Fixes #650

view details

push time in 6 days

PR merged bazelbuild/bazel-gazelle

update-repos can work with a go.mod file in place

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

+23 -44

2 comments

2 changed files

dragonsinth

pr closed time in 6 days

issue closedbazelbuild/bazel-gazelle

Gazelle erroring on relative path replace directives

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.

closed time in 6 days

cwaeland
PullRequestReviewEvent

push eventbazelbuild/rules_go

Zhongpeng Lin

commit sha 67cbb43b3b3c7089c274ffb588ab015ab4e510f9

Redirecting all stdout of subcommands to stderr (#2656) 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

view details

push time in 6 days

PR merged bazelbuild/rules_go

Redirecting all stdout of subcommands to stderr cla: yes

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

+3 -1

0 comment

1 changed file

linzhp

pr closed time in 6 days

PullRequestReviewEvent

issue commentbazelbuild/bazel-gazelle

Magic comment to keep manually added go_repository attributes in generated repositories

# 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",
)
sitaktif

comment created time in 6 days

issue commentgolang/go

proposal: cmd/go: 'go install' should install executables in module mode outside a module

@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.

jayconrod

comment created time in 6 days

create barnchjayconrod/rules_go

branch : update-gazelle

created branch time in 7 days

delete branch jayconrod/bazel-gazelle

delete branch : fix-repo-doc

delete time in 7 days

push eventbazelbuild/bazel-gazelle

Jay Conrod

commit sha 6413504e0dde3ea40461d491f8a218697daade75

doc: fix alignment in go_repository attr table [skip ci] (#914)

view details

push time in 7 days

PR merged bazelbuild/bazel-gazelle

doc: fix alignment in go_repository attr table [skip ci]

build_naming_convention was misaligned.

+188 -188

0 comment

1 changed file

jayconrod

pr closed time in 7 days

PR opened bazelbuild/bazel-gazelle

doc: fix alignment in go_repository attr table [skip ci]

build_naming_convention was misaligned.

+188 -188

0 comment

1 changed file

pr created time in 7 days

create barnchjayconrod/bazel-gazelle

branch : fix-repo-doc

created branch time in 7 days

delete branch jayconrod/bazel-gazelle

delete branch : fix-dot-name

delete time in 7 days

push eventbazelbuild/bazel-gazelle

Jay Conrod

commit sha b98d31b6591037a80389588b44bd1e1844ed727f

language/go: replace dots with underscores in generated names (#913) Fixes #903

view details

push time in 7 days

issue closedbazelbuild/bazel-gazelle

language/go: generated library name same as source file name

<!-- 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)

closed time in 7 days

asv

create barnchjayconrod/bazel-gazelle

branch : fix-dot-name

created branch time in 7 days

delete branch jayconrod/rules_go

delete branch : fix-conflict-params

delete time in 7 days

push eventbazelbuild/rules_go

Jay Conrod

commit sha b4c392fcfc0a44f2cc5ee3dbb884121dd2ab6957

go: use "shell" params file format instead of "multiline" (#2655) This lets arguments contain newlines. Fixes #2635

view details

push time in 7 days

PR merged bazelbuild/rules_go

go: use "shell" params file format instead of "multiline" cla: yes

This lets arguments contain newlines.

Fixes #2635

+91 -28

0 comment

13 changed files

jayconrod

pr closed time in 7 days

issue closedbazelbuild/rules_go

go: encode newlines in package conflict messages passed to builder

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.

closed time in 7 days

jayconrod
PullRequestReviewEvent

push eventjayconrod/rules_go

Jay Conrod

commit sha c8be4ea3f4d8a6b99e53084522863e1b5d3610a2

fix

view details

push time in 7 days

issue commentgolang/go

cmd/go: get can't work with a non-routeable IP address

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).

dwschulze

comment created time in 7 days

issue commentbazelbuild/rules_go

Printing builder command twice in verbose_failures

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.

linzhp

comment created time in 7 days

Pull request review commentbazelbuild/rules_go

Redirecting errors from compiler to stderr

 func compileGo(goenv *env, srcs []string, packagePath, importcfgPath, asmHdrPath 	args = append(args, "--") 	args = append(args, srcs...) 	absArgs(args, []string{"-I", "-o", "-trimpath", "-importcfg"})-	return goenv.runCommand(args)+	// "go tool compile" writes syntax errors to stdout. Redirecting them to stderr

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

linzhp

comment created time in 7 days

PullRequestReviewEvent
PullRequestReviewEvent

issue openedgolang/go

cmd/link: TestFuncAlign failing at tip on arm64

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

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

created time in 7 days

issue commentbazelbuild/bazel-gazelle

Magic comment to keep manually added go_repository attributes in generated repositories

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.

sitaktif

comment created time in 7 days

pull request commentbazelbuild/rules_go

Create bzl_library entries using gazelle-skylark

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.

achew22

comment created time in 7 days

issue commentbazelbuild/bazel-gazelle

language/go: improve dependency resolution docs; maybe exit non-zero on failure

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
uhthomas

comment created time in 7 days

issue commentbazelbuild/bazel-gazelle

language/go: improve dependency resolution docs; maybe exit non-zero on failure

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).

uhthomas

comment created time in 7 days

issue commentbazelbuild/bazel-gazelle

Magic comment to keep manually added go_repository attributes in generated repositories

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.

sitaktif

comment created time in 7 days

issue commentgolang/go

proposal: cmd/go: notify about newer major versions

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).

zachgersh

comment created time in 7 days

issue commentgolang/go

proposal: cmd/go: default to & improve -mod=readonly

@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).

rsc

comment created time in 7 days

issue commentbazelbuild/bazel-gazelle

language/go: improve dependency resolution docs; maybe exit non-zero on failure

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.

uhthomas

comment created time in 7 days

more