Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Secrus opened this issue Mar 28, 2024 · 2 comments
Open

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

Secrus opened this issue Mar 28, 2024 · 2 comments
Labels
question Further information is requested

Comments

@Secrus
Copy link

Secrus commented Mar 28, 2024

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
Copy link
Owner

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._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 mtkennerly added the question Further information is requested label Mar 28, 2024
@mtkennerly
Copy link
Owner

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:

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants