search

mtkennerly / poetry-dynamic-versioning

Plugin for Poetry to enable dynamic versioning based on VCS tags
MIT License
619 stars 36 forks source link

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

Open Secrus opened 8 months ago

Secrus commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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.

stankudrow commented 4 weeks ago

@Secrus , @mtkennerly , hello. Any progress with this issue? Could you give more details?

Secrus commented 4 weeks ago

@stankudrow not from my side. This is still on the roadmap, but time is limited and there are different priorities too.

mtkennerly commented 4 weeks ago

Glad to hear it's still on the roadmap :) I'd be happy to help test out any changes when it's ready.