thought-machine
Strip the subrepo when it's a plugin defined in the host
The test here contains a good example of this. We have a plugin "foo" and we're building some targets in it. We want to be able to refer to ourselves using the plugin name in the subrepo part of the build label, e.g. ///foo//test:test should work just like //test:test. This doesn't currently work, because we can't resolve this to a subrepo at parse time. It's also harder to resolve this there because we can't modify the label at that point as it's used as a key to synchronise building and parsing dependencies.
This problem is similar to how you should be able to refer to //test:test as ///linux_amd64//test:test, on a linux_amd64 host. To make this work, we strip out the subrepo part of a build label if it matches the host repo when parsing. This PR does something similar, but to avoid leaking a bunch of state from the current parse scope into the parse function, I've opted to move the function onto the scope struct.
If we think this is a nicer approach, then I suggest we move all the ParseBuildLabelContext code into that scope leaving just the raw parsing in core. Parsing would then become a 2 step process: 1) in core, we parse out the various parts of the target, and 2) in the interpreter, we then contextualise that label to the current package being parsed.
Fixes #2465
it seems weird for the Go plugin to try to refer to itself when technically it doesn't know what it'll be called.
The idea was that we ignore what the host repo named the subrepo, and just override it with the plugin ID. This is done when we check the subrepo of the label in BuildLabel.SubrepoLabel(). This means it does always know what it will be called because it defines its plugin ID.
Here's the context for this change: https://github.com/please-build/go-rules/pull/27
I was trying to refer to the go.build_defs from the cgo.build_defs in the go plugin, but couldn't do it in a way that works in the plugin's tests and in production.