Can't resolve plugin name to subrepo when the plugin is the host repo

[Tatskaari]

For example, we're trying to subinclude ///go//build_defs:go here: https://github.com/please-build/go-rules/pull/27

This needs to work.

[stale[bot]]

This issue has been automatically marked as stale because it has not had any recent activity in the past 90 days. It will be closed if no further activity occurs. If you require additional support, please reply to this message. Thank you for your contributions.

[VJftw]

👋 I think i've ran into this too. I'm trying to extend a plugin's build_defs in a repo, then reuse those extended build_defs in other repos. e.g.

graph BT
    PleasePluginRepo["A Please Plugin Repo<br />(VJftw/please-terraform)"]
    AnotherPleasePluginRepo["Another Please Plugin Repo<br />(please-build/go-rules)"]
    CommonPluginExtensionRepo["A Repo that extends the build_defs of the Please Plugin"]
    ProjectRepoA["Project Repo A"]
    ProjectRepoB["Project Repo B"]


    CommonPluginExtensionRepo-->|Extends/configures a Please plugin|PleasePluginRepo
    CommonPluginExtensionRepo-->|Extends/configures a Please plugin|AnotherPleasePluginRepo

    ProjectRepoA-->|Uses common plugin configuration|CommonPluginExtensionRepo
    ProjectRepoB-->|Uses common plugin configuration|CommonPluginExtensionRepo

Does this make sense as something we'd like to support? I'm just trying to reduce the copy and pasting i'm doing between repos. A real-world example that I've managed to hack my way around is here: https://github.com/VJftw/vjpatel.me/pull/17/files where:

graph BT
    PleaseTerraformPluginRepo["Plugin<br />(VJftw/please-terraform)"]
    VJftwInfrastructureRepo["Repo holding extended build_defs to share with other projects<br />(VJftw/infrastructure)"]
    VJftwWebsite["Repo which wants to use the extended build_defs<br />(VJftw/vjpatel.me)"]

    VJftwInfrastructureRepo-->|Extends/configures a Please plugin|PleaseTerraformPluginRepo

    VJftwWebsite-->|Uses common plugin configuration|VJftwInfrastructureRepo

Am I right in thinking that we don't want users to have to define upstream Plugin configuration in .plzconfig and //third_party/plugins/BUILD in their downstream repos, like i've done in https://github.com/VJftw/vjpatel.me/pull/17/files#diff-52b294c0851a6d1aa04211d2912aad32759dd00895338c16358d85de2537ae89 and https://github.com/VJftw/vjpatel.me/pull/17/files#diff-1dd985a1093bfa664a84b9074157ee35e65aac53358ab4d07cfc301c7a061437 ?

[Tatskaari]

If you depend on a plugin that transitively depends on a plugin, you have to define both plugins in the host repo. This was by design, as it follows the general pattern in Please where we don't pull in transitive dependencies automatically. Pragmatically, it sidesteps a huge amount of complexity when trying to resolve versions based on requirements which we didn't want to get involved with.

Whether the configuration is inherited is based on the configuration in the plugin definition. The configuration is inherited from the host repo upwards though, and is mainly to facilitate things like defining command line tools. If we have the following structure (p.s. I had no idea you could do this, this is so cool):

graph BT
    Foolang["Plugin<br />(please-build/foolang-rules)"]
    FoolangRepo["A foolang library<br />(somebody/foolang-lib)<br/> FoocTool=fooc"]
    HostRepo["The host repo <br/> FoocTool=//:fooc"]

    HostRepo --> |FoocTool = //:fooc|Foolang
    HostRepo --> |FoocTool = //:fooc|FoolangRepo
    FoolangRepo --> |FoocTool = //:fooc|Foolang 

You can see that the library uses the toolchain (fooc) defined in the host repo, rather than it's own configuration. There's nothing to go the other way, where the host repo inherits a config value from a repo it subincludes. I'm struggling to see how that might make sense though.

In what way are you trying to extend the terraform rules? Maybe it would be easier if we got in front of a whiteboard?

[Tatskaari]

I have a draft PR up with one approach that might work to fix this: https://github.com/thought-machine/please/pull/2553