We not only use the arguments in our docs. They are also used in downstream to compare signatures between default hooks and the plugin hooks.

IMO there is nothing to fix here. It is totally okay to pass additional args to a function if that's part of the API.

They are also used in downstream to compare signatures between default hooks and the plugin hooks.

I don't think we should enforce that anymore or at the very least change the logic of how we are enforcing that. In fromager we are using a special invoke function to ensure that a function only receives the arguments it needs.

So downstream we will need to ensure that the arguments we are passing in our downstream overrides are a subset of all the possible arguments that can be passed. We don't need strict check of signatures.

It is totally okay to pass additional args to a function if that's part of the API.

IMO it adds technical debt and can make it confusing for initial contributors

In my humble opinion, our special invoke function is not a good design. It's not how typical Python APIs are designed. In a typical Python API, it is the responsibility of the callee to deal with unnecessary arguments, e.g. with **kwargs.

In my humble opinion, our special invoke function is not a good design. It's not how typical Python APIs are designed. In a typical Python API, it is the responsibility of the callee to deal with unnecessary arguments, e.g. with **kwargs.

Yeah, it was a hack to try to avoid introducing breaking changes into the downstream repo when we bumped fromager. It's not an ideal solution, and we should fix that downstream code to use **kwds.

How will we record the formal API of each plugin and then document it if we remove unused arguments from the default functions? Let's figure that out, and then see what that tells us about next steps.