Description of the problem / feature request:

Depending on a local target with a fully qualified label "@local_workspace_name//path/to:target" in repository rules (e.g. java_import_external) is wrongfully considered external.

This issue reproduces both on bazel HEAD and on 0.21.0rc2 (2018-12-03)

For example if a target foo depends on target bar , where both are in the workspace baz_workspace in the following manner

some_repository_rule(
   name = "foo",
   deps = ["@baz_workspace//:bar"],
)

some_rule(
   name = "bar"
)

then bar outputs will reside in external area.

This can cause serious issues for cyclic workspaces, where some labels are fully qualified and some are not.
for instance, depsets will not remove duplicates, which we already saw causes errors for rules that expect no duplicate files...

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

I've reproduce this error with 2 different types of rules:

scala_maven_import_external:
https://github.com/natansil/remap_repro

bazel build //src/a_pkg:boo
...
DEBUG: /Users/natans/tmp/remap_repro/src/a_pkg/repro.bzl:7:17: dep: <generated file external/a/src/a_pkg/foo.jar>

java_import_external - https://github.com/natansil/remap_repro/tree/java_library (same target):

bazel build //src/a_pkg:boo
...
DEBUG: /Users/natans/tmp/remap_repro/src/a_pkg/repro.bzl:7:17: dep: <generated file external/a/src/a_pkg/libfoo.jar>

What operating system are you running Bazel on?

macOS

What's the output of bazel info release?

This issue reproduces on bazel HEAD, 0.21.0rc2 (2018-12-03) and on bazel 0.19.0

@dkelmer @aehlig