What would you need to stop monkeypatching `poetry.core`?

[Secrus]

Hi! I am part of the Poetry core team and actively looking into our plugin API. I am wondering, what would be your "wishlist" of options/APIs you would need to stop monkeypatching poetry.core and replacing the build backend?

[mtkennerly]

Hi! Thanks for reaching out.

The biggest thing would be for Poetry Core to support plugins. poetry-dynamic-versioning uses the build backend wrapper and monkey patching in order to work with Poetry Core even when Poetry itself isn't present.

Aside from that, it would be nice to have an API to tell Poetry that the plugin is changing certain fields from pyproject.toml. Right now, the plugin has to modify a couple of private fields:

https://github.com/mtkennerly/poetry-dynamic-versioning/blob/116259524693e494119519061166d574a79cd3da/poetry_dynamic_versioning/plugin.py#L98-L99

As a general solution, I'd like the plugin API to have a function like:

def load_pyproject(self, pyproject: TOMLDocument) -> None

Poetry would load the initial pyproject.toml and pass it to each plugin sequentially, giving each plugin a chance to change the config (either by mutation or returning a modified copy). Once all modifications are accumulated, Poetry would replace its internal state based on those changes. I'd also want the modified data to end up in the sdist/wheel's pyproject.toml.

[mtkennerly]

Another thing is that this plugin also needs to handle dependencies, not just the main project, since dependencies could also be relying on the plugin for versioning (mainly path/Git dependencies). We also use monkey patching for that:

https://github.com/mtkennerly/poetry-dynamic-versioning/blob/116259524693e494119519061166d574a79cd3da/poetry_dynamic_versioning/plugin.py#L49-L55

I'm not sure if it's better to call the hypothetical load_pyproject method once for each dependency's pyproject.toml as well or have a separate method that's specific to preprocessing dependencies.