New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gazelle: add missing dependencies to WORKSPACE #389

Closed
jayconrod opened this Issue Apr 18, 2017 · 8 comments

Comments

Projects
None yet
4 participants
@jayconrod
Contributor

jayconrod commented Apr 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@chrislovecnm

chrislovecnm Oct 22, 2017

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

chrislovecnm commented Oct 22, 2017

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

@jayconrod

This comment has been minimized.

Show comment
Hide comment
@jayconrod

jayconrod Oct 23, 2017

Contributor

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

jayconrod commented Oct 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@chrislovecnm

chrislovecnm Oct 23, 2017

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.

chrislovecnm commented Oct 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jayconrod

jayconrod Oct 23, 2017

Contributor

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",
)
Contributor

jayconrod commented Oct 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jayconrod

jayconrod Oct 23, 2017

Contributor

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.

Contributor

jayconrod commented Oct 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Xjs

Xjs Nov 23, 2017

Contributor

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?

Contributor

Xjs commented Nov 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jayconrod

jayconrod Nov 27, 2017

Contributor

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

Contributor

jayconrod commented Nov 27, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@ianthehat

ianthehat Dec 21, 2017

Contributor

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

Contributor

ianthehat commented Dec 21, 2017

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

@ianthehat ianthehat closed this Dec 21, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment