Allow Ignoring of pre-loaded packages.

[promiseofcake]

Via the docker_repositories() initialization command it would be great if we had a way to re-use existing dependencies.

Let's say for example I was attempting to build something in the tensorflow/tensorflow tf_workspace, that we have loaded up. It turns out they have already imported six:

https://github.com/tensorflow/tensorflow/blob/master/tensorflow/workspace.bzl#L302

native.bind(
    name = "six",
    actual = "@six_archive//:six",
)

Without being able to override in some manner we are unable to use the docker_build rules in the same workspace. pubref/rules_protobuf an interesting way to handle these sorts of dependencies:
https://github.com/pubref/rules_protobuf#overriding-or-excluding-workspace-dependencies

go_proto_repositories(
  excludes = [
    "com_github_golang_glog",
  ]
)

Which then uses some require logic under the hood to load / not load the repository functions.

In interim I suppose it's possible to manually include the dependencies other than the ones we have already defined and go from there. This seems like something that might get solved as we move towards: bazelbuild/bazel#1943

[mattmoor]

Yeah, I think we can safely add a kwarg for that. I hadn't seen the rules_protobuf stuff, that has a number of interesting features.

[promiseofcake]

Determined that if I changed the ordering of my linked workspaces I circumvented this issue so this is merely a nice to have at this point. Thanks!

[promiseofcake]

Thank you @mattmoor!

[mattmoor]

@promiseofcake My pleasure, sorry this was a little slow.

[promiseofcake]

No worries, thanks also for native.existing_rules().keys(), that is a neat trick.

[promiseofcake]

Same issue when attempting to build containers in a repository that has a tensorflow dependency (which is also providing that bind for com_google_protobuf).

Here is a related issue from the parent containerregistry where this dependency originates: google/containerregistry#36. The problem is that we don't have a way to choose which @six we are providing due to the bind, and there doesn't seem to be a way to programmatically use //external:six or @six//:six.

I can get around this with a fork, kind of, the problem is that we are depending on published artifacts for puller and importer as opposed to their public targets in google/containerregistry. I attempted to swap the local http_file targets with the parent targets @containerregistry//:puller or @containerregistry//:puller.par but those aren't working.

@mattmoor, do you know why we need to use the published artifacts rather than repo's targets?