Ignore recursive symlinks in external dependencies

[lazdmx]

Hi! Are there any way to add external dep with recursive symlinks like https://github.com/jteeuwen/go-bindata?

So, if I have a WORKSPACE like:

...
new_go_repository(
    name = "com_github_jteeuwen_go_bindata",
    commit = "a0ff2567cfb70903282db057e799fd826784d41d",
    importpath = "github.com/jteeuwen/go-bindata",
)

bind(
    name = "go-bindata",
    actual = "@com_github_jteeuwen_go_bindata//go-bindata",
)
...

BUILD file

...
genrule(
    name = "assets",
    srcs = [
		"//<patterns>",
    ],
    outs = ["assets.go"],
    cmd = "$(location //external:go-bindata) -o $@ -nocompress -pkg main -prefix $(@D) $(SRCS)",
    tools = [
        "//external:go-bindata"
    ]
)
...

Since a purpose of go-bindata is to collect files, it is expected that author has tests for recursive links, but this recursive links kills a bazel with error like:

ERROR: /private/var/tmp/_bazel_dimka/360acecf2580728c6a28e523b52ec564/external/com_github_jteeuwen_go_bindata/BUILD:25:12: error globbing [testdata/**]: /private/var/tmp/_bazel_dimka/360acecf2580728c6a28e523b52ec564/external/com_github_jteeuwen_go_bindata/testdata/symlinkRecursiveParent/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget/symlinkTarget (Too many levels of symbolic links).

So for now, a only way (which I know) to make it works, is to go to tmp dir and remove recursive links by hand, but I have a filling that it should be controlled somewhere in go_repository? or maybe it is an issue for other repo....

[jayconrod]

I don't think this is possible with Bazel at the moment.

I tried a more minimal example: just adding this repository as a dependency with new_go_repository, then running bazel query 'kind(go_binary, @com_github_jteeuwen_go_bindata//...)'. I got this error:

ERROR: infinite symlink expansion detected
[start of symlink chain]
/usr/local/google/home/jayconrod/.cache/bazel/_bazel_jayconrod/1df8d8ad4cb35ee83522d81953b4d69f/external/com_github_jteeuwen_go_bindata/testdata/symlinkRecursiveParent
/usr/local/google/home/jayconrod/.cache/bazel/_bazel_jayconrod/1df8d8ad4cb35ee83522d81953b4d69f/external/com_github_jteeuwen_go_bindata/testdata/symlinkRecursiveParent/symlinkTarget
[end of symlink chain]
.
WARNING: Failed to get information about path, for testdata/symlinkRecursiveParent/symlinkTarget, skipping: Infinite symlink expansion.
ERROR: Infinite symlink expansion.

I'll close this issue because it is a general Bazel problem. There doesn't seem to be anything we can do in this repository to work around it. Please consider filing another issue in github.com/bazelbuild/bazel. This may be working as intended though.

As a workaround, consider vendoring this repository and removing that test. You may also be interested in #304, a feature request for similar functionality.

[lazdmx]

@jayconrod thanks. Another way is to externalize util and run in standalone sandboxing, but it forces use another dependency manager in addition to bazel.

By the way, maybe new_go_repository should have an option which disables go_test rule to be generated in BUILD file?

I mean, that external dependency is not a subject for testing... We inspecting and selecting dependency by running tests somewhere but not in project where we gonna use it. Also recursive symlinks and other exceptional stuff are subject to be located in testdata

[jayconrod]

External dependencies frequently are subjects for testing. The tests won't be run unless you run them explicitly (Bazel doesn't provide a way to run all tests in all external dependencies at once, as far as I know), but the go_test rules will be there.

If you need some special handling for BUILD files in an external dependency, a hand-written BUILD file is probably your best bet.