Add support for PEP 517.

[sebastic]

Description

Using setup.py directly is deprecated.

Contributor Declaration

By opening this pull request, I affirm the following:

• All authors agree to the Contributor License Agreement.
• The code follows the project's coding standards.
• I have performed self-review and added comments where needed.
• I have added or updated tests to verify that my changes are effective and functional.
• I have run all existing tests and confirmed they pass.

[Copilot]

Pull request overview

Adds a minimal pyproject.toml declaring a PEP 517 build backend (setuptools), so the package can be built without invoking setup.py directly.

Changes:

• Introduce pyproject.toml with a [build-system] table specifying setuptools as the build backend.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[cristian-codorean]

Thanks for this @sebastic. I pushed a follow-up commit (cead854) to take it a bit further, because the minimal [build-system] table on its own actually breaks the build.

The problem with [build-system] alone

Adding the table flips pip/build into PEP 517 isolated builds. Under isolation, setup.py runs with the project root off sys.path, so its top-level import ecmwfapi (used for version and description) raises ModuleNotFoundError. This breaks both pip install -e . and python -m build:

File "<string>", line 17, in <module>
ModuleNotFoundError: No module named 'ecmwfapi'

(Note this also affects the unpinned requires = ["setuptools"] — in isolation pip pulls the latest setuptools rather than reusing the environment's.)

What the follow-up commit does

• Moves all metadata into a [project] table (PEP 621).
• Derives the version statically via [tool.setuptools.dynamic] attr = "ecmwfapi.api.VERSION" — read by AST, no import, so it works under build isolation.
• Deletes setup.py (no longer needed).
• Pins setuptools>=64 (PEP 660 editable + PEP 621 [project] support).
• Sets requires-python = ">=3.8" to match the CI matrix, and drops the Python :: 2 classifier — no py2 wheel is published and CI doesn't test py2, so the classifier was overstating support. Happy to adjust this if py2 or earlier Python 3 versions (e.g. 3.7) still matter to you — requires-python can be lowered, and preserving py2 source installs would mean keeping setup.py and marker-pinning setuptools instead of the [project] table.

Verification

pip install -e ., python -m build (sdist + wheel), and a clean wheel install + import all succeed locally with version 1.6.5. CI confirms the editable build now succeeds across all 18 matrix jobs.

Red CI

Unrelated to packaging — the two failing integration tests need the ECMWFAPIRC secret, which GitHub withholds from fork-based PR runs. They should pass once merged.

[sebastic]

Thanks for this @sebastic. I pushed a follow-up commit (cead854) to take it a bit further, because the minimal [build-system] table on its own actually breaks the build.

The problem with [build-system] alone

Adding the table flips pip/build into PEP 517 isolated builds. Under isolation, setup.py runs with the project root off sys.path, so its top-level import ecmwfapi (used for version and description) raises ModuleNotFoundError. This breaks both pip install -e . and python -m build:

File "<string>", line 17, in <module>
ModuleNotFoundError: No module named 'ecmwfapi'

(Note this also affects the unpinned requires = ["setuptools"] — in isolation pip pulls the latest setuptools rather than reusing the environment's.)

We get around that in the Debian packaging by setting PYTHONPATH:

export PYTHONPATH=$(CURDIR)

Something similar should work for your CI setup as well.

[cristian-codorean]

Thanks for the feedback, I guess something you won't have to do anymore.

Will merge and prepare a new release soon.

[cristian-codorean]

Version 1.7.0 now released.

https://pypi.org/project/ecmwf-api-client/