feat: fallback to gather metadata via pep517 if reading as Poetry project raises RuntimeError

[finswimmer]

At the moment Poetry gives up gather metadata from a Poetry project during installation/locking if parsing the pyproject.toml raises a RuntimeError. This currently happens if one tries to add a Poetry project whose pyproject.toml contains group-dependencies introduced in Poetry 1.2, but the Poetry in use is <1.2. Similar scenarios are possible in the future whenever something changed in the appearance of the pyproject.toml.

With this PR we catch the RuntimeError and fallback to pep517 to gather the metadata, making the process more robust.

Once accepted I would suggest to backport it to Poetry 1.1 and cut a new release immediately, hoping to make the transition period between 1.1 and 1.2 more smooth, by avoiding things like #5761.

• Added tests for changed code.
• Updated documentation for changed code.

[dimbleby]

RuntimeError is a rather broad exception, and the scope at which it is suppressed is rather large in two of the three changed files. This risks masking errors other than the one you are aiming at.

• too late to help if this does get back-applied to poetry 1.1: but can poetry-core be taught to throw a more specific exception on failing to parse the pyproject.toml?
• can the scope of the exception handling be narrowed here?

[radoering]

• too late to help if this does get back-applied to poetry 1.1: but can poetry-core be taught to throw a more specific exception on failing to parse the pyproject.toml?

I agree we should do this at least for future versions.

• can the scope of the exception handling be narrowed here?

Had the same thought and then forgot to mention it. It probably can since we are only expecting an exception from Factory.create_poetry(). At least that's my understanding.

[dimbleby]

re throwing a more precise exception: there's an existing PyProjectException which would probably be fine both here and here, these should be the two that are relevant I think.

[finswimmer]

• can the scope of the exception handling be narrowed here?

Probably it can, but it looks a bit ugly:

try:
    package_poetry = Factory().create_poetry(pyproject.file.path.parent)
except RuntimeError:
    pass
else:
    builder: Builder
    if package.develop and not package_poetry.package.build_script:
        from poetry.masonry.builders.editable import EditableBuilder
        ...

Is it worth it? 🤔

[dimbleby]

package_poetry = None
if pyproject.is_poetry_project():
    with contextlib.suppress(RuntimeError):
        package_poetry = Factory().create_poetry(pyproject.file.path.parent)

if package_poetry is not None:
    etc

?

[finswimmer]

Much nicer 👍

I decided for:

if pyproject.is_poetry_project():
    try:
        package_poetry = Factory().create_poetry(pyproject.file.path.parent)
    except RuntimeError:
        package_poetry = None

    if package_poetry is not None:
        ...

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.