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

Refactor code to support multiple project type #567

Closed
wants to merge 9 commits into from

Conversation

sdispater
Copy link
Member

Resolves: python-poetry/roadmap#3

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

@github-advanced-security
Copy link

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.

@sdispater sdispater force-pushed the refactor/multiple-project-type-take-2 branch 2 times, most recently from 77882e4 to 7bc1f68 Compare March 20, 2023 22:33
@sonarcloud
Copy link

sonarcloud bot commented Mar 20, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 7 Code Smells

No Coverage information No Coverage information
5.0% 5.0% Duplication

@sdispater sdispater force-pushed the refactor/multiple-project-type-take-2 branch 2 times, most recently from f7f838d to 401f9a2 Compare April 25, 2023 19:53
@sdispater sdispater force-pushed the refactor/multiple-project-type-take-2 branch from e625ae8 to 1aece4a Compare May 21, 2023 17:56
@sonarcloud
Copy link

sonarcloud bot commented May 21, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 13 Code Smells

No Coverage information No Coverage information
6.8% 6.8% Duplication

@sdispater sdispater force-pushed the refactor/multiple-project-type-take-2 branch from 7b78578 to 7f204da Compare July 10, 2023 21:24
@sonarcloud
Copy link

sonarcloud bot commented Jul 10, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 13 Code Smells

No Coverage information No Coverage information
7.8% 7.8% Duplication

@austinlucaslake
Copy link

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

@jordantshaw
Copy link

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

@GabDug
Copy link

GabDug commented Nov 7, 2023

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

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

brendanodwyer commented Feb 23, 2024

@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
Copy link
Member

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

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

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

@neersighted neersighted deleted the refactor/multiple-project-type-take-2 branch March 26, 2024 01:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support for PEP 621
7 participants