Add, update, and remove repository rules

[bazelbuild]

Add, update, and remove repository rules

[ashi009]

I guess this will not come before vgo hits GA?

[jayconrod]

Not sure what you mean by GA. The earliest vgo could possibly become the official Go build system is Go 1.12 (next winter). It will be shipped in the 1.11 SDK as an experimental tool.

I'll get this functionality in as soon as I can, but there are a lot of things going on in parallel right now. We'll probably want more direct support for importing vgo mod files, too.

[ashi009]

Scratch GA. After GA, I think it will take a while before the vgo versioning system is “generally adopted” ;-) Jay Conrod <[email protected]>于2018年6月28日 周四下午10:24写道：

…

Not sure what you mean by GA. The earliest vgo could possibly become the official Go build system is Go 1.12 (next winter). It will be shipped in the 1.11 SDK as an experimental tool. I'll get this functionality in as soon as I can, but there are a lot of things going on in parallel right now. We'll probably want more direct support for importing vgo mod files, too. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#56 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAp9BzwGRIOasEqkC7fEDxRWrhdcW2Bwks5uBOcxgaJpZM4RNwik> .

[clintberry]

The link to the tool that adds repo rules to WORKSPACE doesn't appear to work anymore. The link is in this comment: bazelbuild/rules_go#295 (comment)

What is the latest and greatest way to update the WORKSPACE with all my external dependencies automagically? :-)

[linzhp]

To get the transitive dependencies of an external package, I am thinking about the following:

1. Create a Go module in TempDir
2. Convert the existing go_repository rules into the new go.mod file in TempDir.
3. Run go get import/[email protected] in the TempDir
4. Add/update existing go_repository rules based on the new go.mod/go.sum files

I don't want to assume go.mod file exists in the main repo, and instead use go_repository rules as the source of truth in Step 2.

@jayconrod What do you think?

[jayconrod]

@linzhp I'm not sure the go command should be involved at all in this process. There may be a number of workspaces declared with http_archive or other repository rules, and go get won't be able to work with those. Gazelle won't be able to update those, but it should still be able to load dependencies from them.

Some more thought also needs to go into making this language agnostic.

[linzhp]

I agree that we should make this language agnostic by having each language extension implement how they get their dependencies and resolve the versions. But for Go, I don't see a big issue with the "go get" approach:

• With close to 1000 external libraries we are using in our Go repo, we don't see any other Go library except Gazelle itself for which we cannot use go_repository. We even use go_repository for some repos that only contain proto files and use them to generate Go code at build time.
• Gazelle only generates go_repository rules for Go libraries. I think it's a fair assumption that if people decide to use http_archive or other workspace rules to download their Go libraries, they will have to manage those rules themselves.
• With no public API available, go get seems the only way we can resolve the transitive deps and their version in a consistent way to the Go modules system. Gazelle calls other go subcommands anyway.