Allow builifier and buildozer to be run via a rule

[ash2k]

Would be great to be able to use buildifier and buildozer via a rule that downloads what's needed and builds these tools automatically. go get ... is not the best user experience.
Gazelle is very convenient to use https://github.com/bazelbuild/bazel-gazelle#running-gazelle-with-bazel

[ash2k]

Related #170

[pmbethe09]

What do you mean by 'rule'?
In a bazel world if you include com_github_bazelbuild_buildtools in your WORKSPACE
then you can build/run/use buildifier/buildozer via
@com_github_bazelbuild_buildtools//buildifier
@com_github_bazelbuild_buildtools//buildozer

[pmbethe09]

ah, I see you want to operate on files in the current workspace.

https://blog.bazel.build/2018/04/11/bazel-0.12.html
there is a new flag --direct_run plus environment variables in that post for doing as you want

[jacobstr]

I wanted to explore the suggestion of including com_github_bazelbuild_buildtools in my WORKSPACE. This is a quick play-by-play:

The (abridged) setup. Running bazel 0.11.1.

# WORKSPACE
go_repository(
    name = "com_github_bazelbuild_buildtools",
    importpath = "github.com/bazelbuild/buildtools",
    commit = "331d283a59329fee6ca033fbaf8f7560b2be3718",
)

# BUILD
alias(
    name = "buildozer",
    actual = "@com_github_bazelbuild_buildtools_two//buildozer"
)

The result:

bazel run //:buildozer
ERROR: /private/var/tmp/_bazel_jacob/356a8a15beef06fa16abc554ad147a1a/external/com_github_bazelbuild_buildtools/buildozer/BUILD.bazel:10:1: @com_github_bazelbuild_buildtools//buildozer:buildozer: no such attribute 'library' in 'go_binary' rule

I recognize the error as relating to a change from importpath to embed in rules_go. It looks like something else is already including com_github_bazelbuild_buildtools and the go_repository rule in my workspace is being shadowed by it (the contents of the BUILD.bazel do not match the contents of the file at the commit I want, which does indeed use embed).

Incidentally, if someone has a protip on how track what's pushing this external dependency into my workspace, I'm very curious.

A kludge was to modify the name of the WORKSPACE target e.g. com_github_bazelbuild_buildtools_two. That gets us further:

WARNING: /private/var/tmp/_bazel_jacob/356a8a15beef06fa16abc554ad147a1a/external/com_github_bazelbuild_buildtools_two/WORKSPACE:1: Workspace name in /private/var/tmp/_bazel_jacob/356a8a15beef06fa16abc554ad147a1a/external/com_github_bazelbuild_buildtools_two/WORKSPACE (@com_github_bazelbuild_buildtools) does not match the name given in the repository's definition (@com_github_bazelbuild_buildtools_two); this will cause a build error in future versions

Moving on:

ERROR: /private/var/tmp/_bazel_jacob/356a8a15beef06fa16abc554ad147a1a/external/com_github_bazelbuild_buildtools_two/build_proto/BUILD.bazel:10:1: no such package '@io_bazel//src/main/protobuf': The repository could not be resolved and referenced by '@com_github_bazelbuild_buildtools_two//build_proto:copy_and_fix'

This, I suspect is related to this thread: https://groups.google.com/forum/#!topic/bazel-discuss/EBeFucaAg3A. We don't pull the transitive dep on io_bazel.

Seems like it's both a blessing and a curse to inject external dependencies - I wonder if external targets could be scoped so that they were otherwise invisible to my workspace.

Just a bit more yak shaving in the WORKSPACE:

http_archive(
    name = "io_bazel",
    sha256 = "e5321afb93e75cfb55f6f9c34d44f15230f8103677aa48a76ce3e868ee490d8e",
    strip_prefix = "bazel-0.11.1",
    urls = [
        "http://mirror.bazel.build/github.com/bazelbuild/bazel/archive/0.11.1.tar.gz",
        "https://github.com/bazelbuild/bazel/archive/0.11.1.tar.gz",
    ],
)

This almost gets me there, with the exception that I need to upgrade to Bazel 0.12 for --direct_run.

Some context - what I'm ultimately aiming for is to have a single rule to re-gazelle our repo and work around issues where otherwise unused test dependencies cause a build-the-world to fail:

• run gazelle
• run buildozer with delete '//vendor/...:%go_test' to remove test dependencies, related: Optionally disable generation of go_test rules for vendor and dependencies bazel-gazelle#37

[ash2k]

The experience above is not as great as with Gazelle. Which is trivial to setup and use. That is what I'm after :)

[ash2k]

My attempt at doing this #318