-
Notifications
You must be signed in to change notification settings - Fork 245
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
Add support for the project
section (PEP 621)
#708
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Mar 10, 2024
Open
1 task
1 task
another way to do this would be not-chaning poetry's internal layout of configuration at all, and just mapping the |
3ad5fc8
to
2dd952d
Compare
|
2dd952d
to
c828b6c
Compare
edgarrmondragon
added a commit
to edgarrmondragon/tap-betterstack
that referenced
this pull request
May 3, 2024
edgarrmondragon
added a commit
to edgarrmondragon/tap-betterstack
that referenced
this pull request
May 3, 2024
edgarrmondragon
added a commit
to edgarrmondragon/tap-betterstack
that referenced
this pull request
May 3, 2024
edgarrmondragon
added a commit
to edgarrmondragon/tap-betterstack
that referenced
this pull request
May 3, 2024
edgarrmondragon
added a commit
to edgarrmondragon/tap-betterstack
that referenced
this pull request
May 3, 2024
4 tasks
radoering
added a commit
to radoering/poetry-core
that referenced
this pull request
May 19, 2024
- introduce schema for [project] section - soften schema for [tool.poetry] section so that there are no mandatory fields - deprecate fields in [tool.poetry] that can be completely replaced by fields in [project] - add possibility to add supplementary dependency information in [tool.poetry.dependencies] - add warnings for deprecated and duplicated fields in Factory.validate() Co-authored-by: Sébastien Eustace <sebastien@eustace.io>
radoering
added a commit
to radoering/poetry-core
that referenced
this pull request
May 19, 2024
…on from [tool.poetry] dependencies for locking (python-poetry#708)
radoering
added a commit
to radoering/poetry-core
that referenced
this pull request
May 19, 2024
…res-python] and [tool.poetry.dependencies.python] (python-poetry#708) - the first one is used for building and the second one for locking - the second one has to be a subset of the first one - if only one of both is defined, it is used for building and locking
radoering
added a commit
to radoering/poetry-core
that referenced
this pull request
May 19, 2024
…n-poetry#708) - if classifiers are declared in the [project] section they are static - if classifiers are declared as dynamic in the [project] section, they can be declared in the [tool.poetry] section and enriched by license and requires-python information
radoering
added a commit
to radoering/poetry-core
that referenced
this pull request
May 19, 2024
…ipts, ignore extras in entry points (python-poetry#708)
radoering
added a commit
to radoering/poetry-core
that referenced
this pull request
May 19, 2024
edgarrmondragon
added a commit
to edgarrmondragon/poetry-dynamic-versioning
that referenced
this pull request
May 19, 2024
radoering
added a commit
to radoering/poetry-core
that referenced
this pull request
May 20, 2024
radoering
added a commit
to radoering/poetry-core
that referenced
this pull request
Sep 1, 2024
radoering
added a commit
to radoering/poetry-core
that referenced
this pull request
Sep 1, 2024
…tps://json.schemastore.org/pyproject.json and support strings in the license field (python-poetry#708)
radoering
added a commit
to radoering/poetry-core
that referenced
this pull request
Sep 1, 2024
- introduce schema for [project] section - soften schema for [tool.poetry] section so that there are no mandatory fields - deprecate fields in [tool.poetry] that can be completely replaced by fields in [project] - add possibility to add supplementary dependency information in [tool.poetry.dependencies] - add warnings for deprecated and duplicated fields in Factory.validate() Co-authored-by: Sébastien Eustace <sebastien@eustace.io>
radoering
added a commit
to radoering/poetry-core
that referenced
this pull request
Sep 1, 2024
…on from [tool.poetry] dependencies for locking (python-poetry#708)
radoering
added a commit
to radoering/poetry-core
that referenced
this pull request
Sep 1, 2024
…res-python] and [tool.poetry.dependencies.python] (python-poetry#708) - the first one is used for building and the second one for locking - the second one has to be a subset of the first one - if only one of both is defined, it is used for building and locking
radoering
added a commit
to radoering/poetry-core
that referenced
this pull request
Sep 1, 2024
…n-poetry#708) - if classifiers are declared in the [project] section they are static - if classifiers are declared as dynamic in the [project] section, they can be declared in the [tool.poetry] section and enriched by license and requires-python information
radoering
added a commit
to radoering/poetry-core
that referenced
this pull request
Sep 1, 2024
…ipts, ignore extras in entry points (python-poetry#708)
radoering
added a commit
to radoering/poetry-core
that referenced
this pull request
Sep 1, 2024
radoering
added a commit
to radoering/poetry-core
that referenced
this pull request
Sep 1, 2024
91afc0e
to
312a32c
Compare
radoering
added a commit
to radoering/poetry-core
that referenced
this pull request
Sep 1, 2024
…tps://json.schemastore.org/pyproject.json and support strings in the license field (python-poetry#708)
Secrus
approved these changes
Sep 2, 2024
- introduce schema for [project] section - soften schema for [tool.poetry] section so that there are no mandatory fields - deprecate fields in [tool.poetry] that can be completely replaced by fields in [project] - add possibility to add supplementary dependency information in [tool.poetry.dependencies] - add warnings for deprecated and duplicated fields in Factory.validate() Co-authored-by: Sébastien Eustace <sebastien@eustace.io>
…on from [tool.poetry] dependencies for locking (python-poetry#708)
…res-python] and [tool.poetry.dependencies.python] (python-poetry#708) - the first one is used for building and the second one for locking - the second one has to be a subset of the first one - if only one of both is defined, it is used for building and locking
…n-poetry#708) - if classifiers are declared in the [project] section they are static - if classifiers are declared as dynamic in the [project] section, they can be declared in the [tool.poetry] section and enriched by license and requires-python information
…ipts, ignore extras in entry points (python-poetry#708)
…tps://json.schemastore.org/pyproject.json and support strings in the license field (python-poetry#708)
312a32c
to
8f2cdac
Compare
radoering
added a commit
that referenced
this pull request
Sep 2, 2024
- introduce schema for [project] section - soften schema for [tool.poetry] section so that there are no mandatory fields - deprecate fields in [tool.poetry] that can be completely replaced by fields in [project] - add possibility to add supplementary dependency information in [tool.poetry.dependencies] - add warnings for deprecated and duplicated fields in Factory.validate() Co-authored-by: Sébastien Eustace <sebastien@eustace.io>
radoering
added a commit
that referenced
this pull request
Sep 2, 2024
…on from [tool.poetry] dependencies for locking (#708)
radoering
added a commit
that referenced
this pull request
Sep 2, 2024
…res-python] and [tool.poetry.dependencies.python] (#708) - the first one is used for building and the second one for locking - the second one has to be a subset of the first one - if only one of both is defined, it is used for building and locking
radoering
added a commit
that referenced
this pull request
Sep 2, 2024
- if classifiers are declared in the [project] section they are static - if classifiers are declared as dynamic in the [project] section, they can be declared in the [tool.poetry] section and enriched by license and requires-python information
radoering
added a commit
that referenced
this pull request
Sep 2, 2024
…ipts, ignore extras in entry points (#708)
radoering
added a commit
that referenced
this pull request
Sep 2, 2024
radoering
added a commit
that referenced
this pull request
Sep 2, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #567
should not be squashed
Hints:
project
section (PEP 621) poetry#9135Notable changes compared to #567 or "why I did not just rebase it":
tool.poetry
and one forproject
). Reasoning:project
fields are optional.project
section and thetool.poetry
section in the PEP 621 compatible schema.project
section and thetool.poetry
section. However, this would require heavy use ofanyOf
(because of the non-package mode) and this results in hard-to-understand error messages, seepoetry-core/src/poetry/core/factory.py
Lines 390 to 404 in 7d40189
anyOf
and validate the relation between both sections in thevalidate()
method anyway.[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]
).[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.tool.poetry
that can be completely replaced by fields in theproject
section, seeFactory.validate()
.