New structure for PythonProject

[garysassano]

A few things I would like to change for PythonProject:

• pyproject.toml is the new standard configuration file for all projects, completely replacing the old requirements.txt.

• A new requiresPython prop that follows pyproject.toml PyPA spec is introduced, with the following default value:

  • >=3.9

• A new packageManager prop is introduced, with the following valid values:

  • UV (default)
  • PIP
  • PDM
  • POETRY
  • CONDA

• A new buildSystem prop that follows PEP 517 is introduced, with the following valid values:

  • SETUPTOOLS (default)
  • POETRY (default when packageManager is POETRY)

• A new formatAndLinting array prop is introduced, with the following valid values:

  • RUFF (default)
  • BLACK
  • FLAKE8
  • YAPF
  • AUTOPEP8
  • PYLINT
  • PYCODESTYLE

[garysassano]

Possible non-issues when moving pyproject.toml to PythonProject:

• pyproject.toml currently doesn't support "non-package projects" (something that PEP 735 aims to address), so all Python projects would need to be created inside a package directory having the same name as the project (this isn't a big deal and it's actually what we already do for PoetryProject).

  • Poetry recently decided to directly address this issue in v1.8.0 by introducing a custom non-package option which can be set to true. See Enforce Poetry >= 1.8.0 for AwsCdkPythonApp with optional poetry: true #3403 for a more detailed explanation.

• Conda doesn't currently support pyproject.toml, but it will eventually be supported (not a real issue since projen doesn't support it either at the moment).

[mrgrain]

This probably needs to be an RFC:

• prefix the issue title with RFC
• solicit feedback from the community

[automartin5000]

This is awesome. I've been thinking for a while that it would be great to provide the same developer experience to other tools that's provided for/with Poetry.

The Astral tools do look promising, and I might personally opt for them in our teams' projects. However, I worry about making them the default. That especially seems aggressive given that uv was just released. If we can abstract the same general developer experience with standard tooling pip, venv, flake8, etc, then I would vote for that to be the default.