Skip to content

Add support for the project section (PEP 621)#708

Merged
radoering merged 8 commits intopython-poetry:mainfrom
radoering:pep621-support
Sep 2, 2024
Merged

Add support for the project section (PEP 621)#708
radoering merged 8 commits intopython-poetry:mainfrom
radoering:pep621-support

Conversation

@radoering
Copy link
Member

@radoering radoering commented Mar 10, 2024

Closes #567

should not be squashed

Hints:

Notable changes compared to #567 or "why I did not just rebase it":

  • Instead of two complete schemas (one legacy and one PEP 621), I decided to introduce two partial schemas (one for tool.poetry and one for project). Reasoning:
    • By introducing the non-package mode, having one legacy schema and one PEP 621 schema as in Refactor code to support multiple project type #567 does not work well anymore. In non-package mode all project fields are optional.
    • Further, I had difficulties distinguishing the definitions of the project section and the tool.poetry section in the PEP 621 compatible schema.
    • Using a complete schema makes it easier to define relations between the project section and the tool.poetry section. However, this would require heavy use of anyOf (because of the non-package mode) and this results in hard-to-understand error messages, see
      # json validation may only say "data cannot be validated by any definition",
      # which is quite vague, so we try to give a more precise error message
      generic_error = "data cannot be validated by any definition"
      if generic_error in validation_errors:
      package_mode = config.get("package-mode", True)
      if not isinstance(package_mode, bool):
      validation_errors[validation_errors.index(generic_error)] = (
      f"Invalid value for package-mode: {package_mode}"
      )
      elif package_mode:
      required = {"name", "version", "description", "authors"}
      if missing := required.difference(config):
      validation_errors[validation_errors.index(generic_error)] = (
      f"The fields {sorted(missing)} are required in package mode."
      )
      Thus, it makes more sense not to use anyOf and validate the relation between both sections in the validate() method anyway.
  • See Refactor code to support multiple project type #567 (comment)
    • 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.
  • Deprecate fields in tool.poetry that can be completely replaced by fields in the project section, see Factory.validate().

@earonesty
Copy link

another way to do this would be not-chaning poetry's internal layout of configuration at all, and just mapping the project section's features into poetry's features, right?

@radoering radoering force-pushed the pep621-support branch 2 times, most recently from 3ad5fc8 to 2dd952d Compare March 29, 2024 10:04
@sonarqubecloud
Copy link

Quality Gate Passed Quality Gate passed

Issues
8 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

edgarrmondragon added a commit to reservoir-data/tap-betterstack that referenced this pull request May 3, 2024
edgarrmondragon added a commit to reservoir-data/tap-betterstack that referenced this pull request May 3, 2024
edgarrmondragon added a commit to reservoir-data/tap-betterstack that referenced this pull request May 3, 2024
edgarrmondragon added a commit to reservoir-data/tap-betterstack that referenced this pull request May 3, 2024
edgarrmondragon added a commit to reservoir-data/tap-betterstack that referenced this pull request May 3, 2024
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
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
radoering added a commit to radoering/poetry-core that referenced this pull request May 19, 2024
@radoering radoering marked this pull request as ready for review May 19, 2024 13:40
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 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
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
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
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
radoering added a commit to radoering/poetry-core that referenced this pull request Sep 1, 2024
radoering and others added 8 commits September 2, 2024 17:12
- 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>
…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
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.

7 participants