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:

poetry-dynamic-versioning/poetry_dynamic_versioning/plugin.py

Lines 98 to 99 in 1162595

	poetry._package._version = PoetryCoreVersion.parse(version)
	poetry._package._pretty_version = version

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:

poetry-dynamic-versioning/poetry_dynamic_versioning/plugin.py

Lines 49 to 55 in 1162595

	@functools.wraps(Factory.create_poetry)
	def patched_create_poetry(*args, **kwargs):
	instance = original_create_poetry(*args, **kwargs)
	_apply_version_via_plugin(instance, io=io)
	return instance
	Factory.create_poetry = patched_create_poetry

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]

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

[Secrus]

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

[mtkennerly]

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