Gazelle: add missing dependencies to WORKSPACE

[jayconrod]

Gazelle should provide a mechanism to add new_go_repository rules to the WORKSPACE file in order to resolve import paths for missing external dependencies. This should be behind a flag (say, -update_workspace). When an external dependency is added, its dependencies should be added recursively.

When a new dependency is added, Gazelle should try to use a known version of that dependency, if possible. For example, suppose we want to add a dependency on "foo" because our dependency "bar" has "foo" in its vendor directory, which is managed with Godep. We should read Godeps.json to determine the preferred version of "foo".

When a dependency that was automatically added by Gazelle is no longer needed, we should remove it from WORKSPACE (again, behind a flag). We should avoid removing any rules manually added by the developer. If this can't be done safely, we should at least emit a warning.

[chrislovecnm]

Pretty please?? Sugar on top. Automating this would be HUGE

[jayconrod]

This is definitely still planned, but a lot of work is needed.

The rough design right now is to add four commands:

• add-deps: add new dependencies, optionally including transitive dependencies. Possibly automatic, based on import paths that can't be resolved.
• update-deps: update existing dependencies to newer versions. Can optionally add or delete dependencies which are newly needed or no longer needed.
• rm-deps: remove existing dependencies. Possibly automatic, based on import paths.
• sync-deps: transcribe dependencies from dep's lock file or some other equivalent. This could probably be done earlier.

[chrislovecnm]

Just starting simple where it adds a new block for the user with the expected name would be super. Just have the user out in the git URL and the sha.

If we can get someone in that helps with typing and then make it smart later.

Also I think bazel has feature flags? Fairly new to this project.

[jayconrod]

Just starting simple where it adds a new block for the user with the expected name would be super. Just have the user out in the git URL and the sha.

There's actually a tool that does this, but I intend to delete it as soon as Gazelle is capable of replacing this. You can find it in go/tools/wtool (go get -u github.com/bazelbuild/rules_go/go/tools/wtool). Normally, you'll want to use it with the -asis flag. For example:

wtool -asis golang.org/x/sys

This would add this block to WORKSPACE (it figures out the sha1 automatically):

go_repository(
    name = "org_golang_x_sys",
    commit = "8dbc5d05d6edcc104950cc299a1ce6641235bc86",
    importpath = "golang.org/x/sys",
)

[jayconrod]

Also I think bazel has feature flags? Fairly new to this project.

Do you mean support for build tags (// +build comments)? We recognize and apply those constraints automatically, but we don't have a way to turn on custom tags yet.

[Xjs]

Found this issue and #295 while trying to find any links between bazel and dep. To me it seems dep and bazel/gazelle might complement each other in a beneficial way (I actually have done this productively already by half-automatically creating parts of the WORKSPACE file from dep's Gopkg.lock file).

Is there any endeavour to use the files generated by dep to generate the WORKSPACE file, or to create some other kind of link from dep to bazel? Am I missing something?

[jayconrod]

@Xjs There is some work planned for this. Gazelle will have a command (something like migrate-deps or import-deps) that will import rules from dep, or glide, or other vendoring tools.

We're planning to deprecate go_repository though, so I hesitate to generate go_repository rules. The long term plan is for Gazelle to generate flat build files for external repositories, then use those with new_git_repository or new_http_archive. The new command should probably do that right off the bat.

[ianthehat]

See bazelbuild/bazel-gazelle#47 for the new update-repos command
Further work will be tracked in bazel-gazelle, so closing this issue