Make generate_workspace visible

[cpenner-va]

Can we set visibility to public on the generate_workspace? I'd love to be able to automatically pull the tool into some of my bazel projects so I can use it more easily, but the target is currently private.

[petroseskinder]

Hi Chris,

Thanks for the feedback. Can you explain your general workflow with generate_workspace? I saw your prior comments on #26 and #24, and I do acknowledge it is somewhat awkward that it cannot be called from within an existing project.

For this specific issue, I'll let @kchodorow answer whether this is an appropriate move. However, for the time being, you can modify migration-tooling/generate_workspace/BUILD file so that it reads:

package(default_visibility = ["//visibility:public"]) #<-- new line to add

java_binary(
    name = "generate_workspace",
    main_class = "com.google.devtools.build.workspace.GenerateWorkspace",
    runtime_deps = ["//generate_workspace/src/main/java/com/google/devtools/build/workspace"],
)

[cpenner-va]

Thanks; the temporary fix I was using was to just run directly from the external package, i.e. bazel run @io_bazel_migration_tooling//generate_workspace;

As far as I can tell the intended use-case for generate_workspace is that it should be used once when converting from one project type to another; we're using it every time that we need to add a new maven dependency.

The reason for this is that oftentimes maven dependencies have transitive dependencies and unifying and hunting them down is a large pain with a good chance of making mistakes. Here's an example of how we're using it:

• Start new project
• Realize we need lib 'X', so generate a workspace with generate_workspace -a com.X:X:1.0
• Work some more...
• Realize we need lib 'Y' so generate a new workspace containing X AND Y via generate_workspace -a com.Y:Y:1.0 -a com.X:Y:1.0

In this way we know we never have duplicates and don't need to figure out transitive dependencies manually.

In order to ease this process we have a shell script which calls generate_workspace for us; something like:

#!/bin/bash
bazel run @io_bazel_migration_tooling//generate_workspace -- -a X:X:1.0 -a Y:Y:1.0 -o /project/dir

By including generate_workspace in our workspace or build file we guarantee that our build scripts and scripts to add libraries "just work" when other team members clone the repo. We don't need to ensure that they've installed the generate_workspace repo somewhere on their machine.

If you need more clarification or have any suggestions on how to improve our workflow then I'm very interested to hear them! Thanks for your work on this!

@jguenther-va, @cede-va

[kchodorow]

Yeah, it absolutely should be public. Stand by.