Declare repository dependencies in child WORKSPACE files #420
Conversation
Bazel is moving to a model where child repository WORKSPACE files will be parsed (see bazelbuild/bazel#1943). This means that top-level WORKSPACE files won't have to declare every dependency (yay!) but, as a part of this, child repositories will have to start declaring the repositories they use. This should be a no-op, though, since the top-level WORKSPACE file overrides all of these repository definitions. So it doesn't really matter what they are (hence the dummy paths).
|
So for every new_go_repository, you have to know what repos it depends on? |
|
Yes. Don't you have to now, anyway? They repository definitions just go in the main WORKSPACE file. |
|
maintaining this 2-way list manually sounds hard |
|
LGTM |
|
How are people doing this now? Just building, seeing what deps are missing, adding a new_go_repo, and rebuilding? |
|
pretty much. there is a bare-bones tool in this repo 'wtool', which I use to add a new_go_repository, then build, then call wtool again for whatever was missing, etc. |
|
We're thinking of giving Gazelle more capabilities for managing the the WORKSPACE file. See #388 and #389. Even if it doesn't end up writing new dependencies to WORKSPACE, it at least needs to be able to read them. If they're hidden in other WORKSPACE files, I don't know how we'll do that. Bazel doesn't really provide any capabilities for querying external repositories, as far as I know. Personally, I'd much rather have a flat WORKSPACE file. |
| {repo_deps} | ||
| """.format( | ||
| workspace_name = ctx.name, | ||
| repo_deps="\n".join(["local_repository(name='%s', path='/dummy')" % r for r in ctx.attr.repo_deps]))) |
There was a problem hiding this comment.
Using local_repository here doesn't make sense to me. Shouldn't Bazel report a conflict if you declare a local_repository in one place and, for example, a git_repository in another place? Seems like that should count as different versions.
Maybe there should be a special use_repository rule?
There was a problem hiding this comment.
I could add a built-in "dummy" repository rule, if that works better for you guys.
|
When are these declarations going to be mandatory in Bazel? I think we're going to have to improve our tooling to support this. |
|
If this is going to cause you guys a lot of issues, I might be able to get away with not having per-repo declarations as long as the main repo declares them. Let me think about it and see if I can implement that tomorrow... |
|
Seems like that will be do-able. |
Bazel is moving to a model where child repository WORKSPACE files will be
parsed (see bazelbuild/bazel#1943). This means
that top-level WORKSPACE files won't have to declare every dependency
(yay!) but, as a part of this, child repositories will have to start
declaring the repositories they use.
This should be a no-op, though, since the top-level WORKSPACE file
overrides all of these repository definitions. So it doesn't really
matter what they are (hence the dummy paths).