Fix pyproject.toml: add PEP 621 build-system and project sections to unblock editable installs

[Copilot]

pip install -e . fails on Python 3.13 because newer pip/setuptools strictly validates pyproject.toml — the file had [tool.*] config but no [build-system] or [project] table, triggering configuration error: project must contain ['version'] properties.

Changes

• [build-system] — declares setuptools>=64 + wheel as the build backend
• [project] — minimal PEP 621 metadata; version and other fields marked dynamic so setup.py remains authoritative
• [tool.setuptools.dynamic] — wires version to flaml.version.__version__, keeping flaml/version.py as the single version source with no duplication

[build-system]
requires = ["setuptools>=64", "wheel"]
build-backend = "setuptools.build_meta"

[project]
name = "FLAML"
dynamic = ["version", "description", "readme", "dependencies", "optional-dependencies", "classifiers"]
requires-python = ">=3.10"
license = { file = "LICENSE" }

[tool.setuptools.dynamic]
version = { attr = "flaml.version.__version__" }

All existing [tool.*] configuration is preserved unchanged.

Original prompt

The GitHub Actions job failed in microsoft/FLAML in workflow .github/workflows/python-package.yml during the Install packages and dependencies step when running pip install -e . on Python 3.13.

Failure details from job 72079181022 in run 24645772957:

• Error: invalid pyproject.toml config: project
• Validation message: configuration error: project must contain ['version'] properties

Relevant files at commit 9d54e5832b158fe5e732372b59a6d49f09b4b80a:

• pyproject.toml currently contains tool configuration and legacy [metadata], but no valid [build-system] / [project] configuration for editable builds.
• setup.py currently reads the package version from flaml/version.py and passes it to setuptools.setup(...).
• flaml/version.py contains the canonical version string: __version__ = "2.5.0".

Please create a pull request that fixes the packaging/build configuration so editable installs succeed in CI, while keeping the only version definition in flaml/version.py if possible.

Requirements:

1. Fix the failing editable install / pyproject validation error.
2. Prefer to keep a single source of truth for the package version in flaml/version.py.
3. Avoid duplicating the version string in both pyproject.toml and version.py unless absolutely necessary.
4. Preserve existing tool configuration in pyproject.toml.
5. Make the minimal safe change needed to unblock CI.

Likely approach:

• Add a valid [build-system] section.
• Add a valid [project] section.
• Configure setuptools so the project version is dynamically read from flaml.version.__version__ (or an equivalent supported mechanism), instead of hardcoding it in pyproject.toml.
• Update any setuptools configuration needed for dynamic metadata.

Please include a concise PR title and implement the fix directly in the repository.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Please find a solution for this failing job. Use the logs, job definition, and any referenced files where the failure occurred. Keep your response focused on the solution and include code suggestions when appropriate.

Assistant: The job is failing during pip install -e . on Python 3.13 because the repository has a pyproject.toml that is not a valid PEP 621 project definition, but pip/setuptools treats it as such when building an editable install. The log shows:

• ValueError: invalid pyproject.toml config: project
• configuration error: project must contain ['version'] properties

Root cause

Your pyproject.toml (at ref 9d54e5832b158fe5e732372b59a6d49f09b4b80a) contains only tool config sections plus a legacy [metadata] table:

• pyproject.toml has [metadata] ... and [tool.*] ...
• It does not contain a [project] table with a version (or a dynamic = ["version"] declaration)

Newer build behavior (and especially Python 3.13 + recent packaging tooling) is stricter: if a pyproject.toml is present, editable builds validate it and expect proper PEP 621 metadata.

Fix (recommended): add a minimal PEP 621 [project] section (and build-system)

Update pyproject.toml to include valid packaging metadata. Minimal example (adjust name/requirements as appropriate for FLAML):

[build-system]
requires = ["setuptools>=64", "wheel"]
build-backend = "setuptools.build_meta"

[project]
name = "flaml"
version = "0.0.0"  # replace with the real version
description = "..."
readme = "README.md"
requires-python = ">=3.10"
license = { file = "LICENSE" }

If you don’t want to hardcode the version in pyproject.toml, you can make it dynamic (only if your setuptools config is set up to provide it):

[project]
name = "flaml"
dynamic = ["version"]

…but then you must ensure setuptools can resolve the version from your existing packaging setup (e.g., via setup.py / setuptools_scm / an attribute). If you don’t already have dynamic version wiring, the simplest and most robust fix is to set version = "..."
directly.

Why this solves the CI failure

The workflow (.github/workflows/python-package.yml at the same ref) runs:

python -m pip install --upgrade pip wheel "setuptools<82"
pip install -e .

That editable install triggers “getting requirements to build editable”, which currently fails because pyproject.toml is invalid. Adding a valid [project] (with version or dynamic) makes the config pass validation and allows the editable install to proceed on Python 3.13 (and the other matrix versions).

Alternative (less ideal): remove/rename pyproject.toml

If you’re not ready to adopt PEP 621 yet, removing pyproject.toml would avoid the validation path—but you’d lose the tool configuration currently stored there (ruff, black, pytest options). The better long-term approach is to keep pyproject.toml and make it PEP 621-compliant as shown above.

User: Please find a solution for this failing job. Use the logs, job def...

This pull request was created from Copilot chat.