Refactor code to support multiple project type

[sdispater]

Resolves: python-poetry/roadmap#3

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

[github-advanced-security]

You have successfully added a new SonarCloud configuration ``. As part of the setup process, we have scanned this repository and found no existing alerts. In the future, you will see all code scanning alerts on the repository Security tab.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
7 Code Smells

No Coverage information
5.0% Duplication

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
13 Code Smells

No Coverage information
6.8% Duplication

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
13 Code Smells

No Coverage information
7.8% Duplication

[austinlucaslake]

What's left outstanding that could get this pull request merged to add PEP 621 support to Poetry?

[jordantshaw]

Is there an ETA on when these changes will be released? PEP621 compliance is the only reason holding me back from using poetry.

[GabDug]

@jordantshaw If you want to try Poetry with PEP621, I made a POC as a Poetry plugin for 1.6.1. Though, is an experimental, untested, one afternoon proof-of-concept and should not be used anywhere near production code.

[austinlucaslake]

@sdispater As I'm eager to use Poetry in my own CI, I'd be happy to help work on anything that needs finishing with this PR. I'm unable to see the logs for the downstream tests that failed. Could you talk a little bit about what failed and potentially what changes could resolve the CI workflow issues?

[brendanodwyer]

@sdispater Is it possible to see the tests that failed on this PR? Would love to see Poetry be PEP 621 compliant and i'm willing to help where I can to help it get there.

[radoering]

The failing tests are not that relevant at the moment. (You cannot see them anymore because the test run was too long ago.)

In my opinion, the first step is to address python-poetry/poetry#3332 (comment) (this PR is still based on the initial proposal from python-poetry/roadmap#3 (comment)).

That's basically:

• Do not introduce [tool.poetry.dependency-options] but keep [tool.poetry.dependencies], just make version optional and implement the distinction/merging of abstract dependencies ([project.dependencies]) and concrete dependencies ([tool.poetry.dependencies]).
• Do not change anything related to [tool.poetry.group]. That especially makes sense since there might be a standard way for dependency groups in the future (see PEP 735) so we can have the same distinction between abstract and concrete dependencies.

I will try to work on that after the 1.8 release of Poetry if nobody beats me to it.

[radoering]

I started to work on it in #708, which actually feels like "almost ready" (but I may have forgotten things).
There is also a downstream PR (python-poetry/poetry#9135), which however is far from being ready.

If someone wants to help:

• You could test the downstream PR Add support for the project section (PEP 621) poetry#9135,
  but please do only test commands that might already work according to the description of the PR.
• You could test Add support for the project section (PEP 621) #708 stand-alone
  (poetry-core build backend without Poetry), i.e.
  • create a pyproject.toml manually and use the project section instead of tool.poetry for some relevant fields
  • add the following to your pyproject.toml:

    [build-system]
    requires = ["poetry-core@git+https://github.com/radoering/poetry-core.git@pep621-support"]
    build-backend = "poetry.core.masonry.api"
    

  • try to build your project with pip (pip wheel .) or build python -m build .
  • check the created sdist/wheel (Can it be installed? Is the metadata correct? Is some metadata missing?)

[neersighted]

Closing this for now as I am doing a branch cleanup here in upstream.