Add support for the project section (PEP 621)

[radoering]

Closes #567

should not be squashed

Hints:

• Do not rebase without updating the downstream branch Add support for the project section (PEP 621) poetry#9135
• Downstream tests were disabled because this will be breaking for downstream

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

    poetry-core/src/poetry/core/factory.py

    Lines 390 to 404 in 7d40189

    	# 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]

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?

[sonarqubecloud]

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