Can't use a label in build_file

[johnynek]

in my workspace (to use scala) I have:

git_repository(
    name = "bazel",
    remote = "https://github.com/bazelbuild/bazel.git",
    commit = "aaff855491f0a6679308c5a6eac43b3a93135bfc")

new_http_archive(
    name = "scala",
    strip_prefix = "scala-2.11.7",
    sha256 = "ffe4196f13ee98a66cf54baffb0940d29432b2bd820bd0781a8316eec22926d0",
    url = "http://downloads.typesafe.com/scala/2.11.7/scala-2.11.7.tgz",
    build_file = "@bazel//tools/build_rules/scala.BUILD",
)

but if that build_file is a label I get:

st-oscar1:bazel-scala-example oscar$ bazel build example-lib
ERROR: Loading failed; build aborted.
INFO: Elapsed time: 0.094s

1. It would be great to be able to use labels there
2. If they are not supported, the error message should say so and exactly where the error was found, not "Loading failed".

[ahumesky]

This is a nifty idea, unfortunately it's not easy to do. A label doesn't distinguish between generated and source files (by design), and if it's a generated file, you can't know the contents of the file because nothing is executed before the build files are known. So now you have a bit of a chicken and egg problem.

[damienmg]

We do use label for Skylark extension that cannot be generated. I think
that would be logical to use label here too.

On Fri, Feb 5, 2016 at 11:54 PM Alex Humesky [email protected]
wrote:

This is a nifty idea, unfortunately it's not easy to do. A label doesn't
distinguish between generated and source files (by design), and if it's a
generated file, you can't know the contents of the file because nothing is
executed before the build files are known. So now you have a bit of a
chicken and egg problem.

—
Reply to this email directly or view it on GitHub
#855 (comment).

[damienmg]

After some discussion with Alex, even though it is feasible, it might not be desirable because of performance issues that might arise.

[johnynek]

Understood. Is the error message at least considered a bug?

It was a bit unclear what was going on with a larger example.

On Friday, February 5, 2016, Damien Martin-Guillerez <
[email protected]> wrote:

After some discussion with Alex, even though it is feasible, it might not
be desirable because of performance issues that might arise.

—
Reply to this email directly or view it on GitHub
#855 (comment).

P. Oscar Boykin, Ph.D. | http://twitter.com/posco | http://pobox.com/~boykin

[damienmg]

Yes definitely, the error reporting is terrible with remote repositories

[benley]

It's also not possible to use labels in load() from within a BUILD file used with a new_http_archive.

For instance:

# WORKSPACE
new_http_archive(
  name = "docker_ubuntu",
  build_file = "BUILD.ubuntu",
  url = "https://codeload.github.com/tianon/docker-brew-ubuntu-core/zip/e406914e5f648003dfe8329b512c30c9ad0d2f9c",
  sha256 = "de31e6fcb843068965de5945c11a6f86399be5e4208c7299fb7311634fb41943",
  type = "zip",
  strip_prefix = "docker-brew-ubuntu-core-e406914e5f648003dfe8329b512c30c9ad0d2f9c")

# BUILD.ubuntu
load("//tools/build_defs/docker:docker.bzl", "docker_build")

docker_build(
  name = "trusty",
  tars = ["trusty/ubuntu-trusty-core-cloudimg-amd64-root.tar.gz"],
  visibility = ["//visibility:public"])

$ bazel build @docker_ubuntu//:trusty
ERROR: error loading package '@docker_ubuntu//': Extension file not found. Unable to load package for '@docker_ubuntu//tools/build_defs/docker:docker.bzl': BUILD file not found on package path.
INFO: Elapsed time: 0.088s

If I change that load statement back to load("/tools/build_defs/docker/docker", "docker_build") then it's able to build successfully, but I hear that syntax is now deprecated and soon to be removed.

[ahumesky]

I believe you can use "@//" to refer to the main repository from an external repository, so "@//tools/build_defs/docker:docker.bzl"

[bsilver8192]

I have that (using load('@//foo:bar.bzl', ...) from a new_http_repository) working.

However, I had to do a bit of work related to issues with labels in the main vs default repositories first. Those changes are currently being reviewed. The big change is I8bd7f7b00bec58a7157507595421bc50c81b404c, but the current patch set on Gerrit is old because it depends on a two other changes which are being reviewed separately. Comments welcome on that and the other two: I3762e6be911b79a133a2959fce3a8bf34d183232 and If337eb2579ae613ba09cab0e0c927691922c0a39.

I'm not sure if any of the halfway fixes made on master since then fixed this particular case, but my main-vs-default-cleanup branch definitely should work.

[benley]

The @// trick worked, thank you for that.

[zaphar]

This still doesn't work for the csharp rules in the bazelbuild/rules_dotnet repsository. If I create a repository and reference the workspace using a local_repository rule in in the WORKSPACE file I get errors saying:

/private/var/tmp/_bazel_jwall/a4f05aced329c5d1ca55a18062777a02/external/io_bazel_rules_dotnet/examples/example_test/BUILD:3:1: every rule of type csharp_nunit_test implicitly depends upon the target '@nunit//:nunit_framework', but this target could not be found because of: no such package '@nunit//': Unable to load package for //dotnet:nunit.BUILD: not found.

The easiest way to replicate is to copy the examples directory out of the rules_dotnet repo into it's own directory and create a WORKSPACE file there like so:

workspace(name="csharp_tests")

local_repository(
    name="io_bazel_rules_dotnet",
    path="/Users/jwall/sandbox/bazel_rules_dotnet",
)

load(
  "@io_bazel_rules_dotnet//dotnet:csharp.bzl",
  "csharp_repositories",
  "csharp_configure",
  "nuget_package",
)

csharp_repositories()
csharp_configure()

Then run bazel fetch @io_bazel_rules_dotnet//... && bazel fetch @ndesk_options//... && bazel test //examples/example_test:MyTest

[zaphar]

Actually after looking at the closure issue it looks like the correct way is to do str(Label(...)) which is non-obvious but fixes the issue. Is this the intended behavior?