Replace setup.py with pyproject.toml

[omad]

Reason for this pull request

I've been using uv a lot because it's brilliantly fast to create/replace virtualenvs. However, it wants package metadata kept in (pyproject.toml)[https://packaging.python.org/en/latest/specifications/pyproject-toml/], as standardised back in 2020, and so I haven't been able to use it with datacube-core.

Datacube core is a pure Python project, and all the metadata (except version) being specified in setup.py is static anyway, so I think this is a nice modernisation and simplification.

This still allows packages to be built with python -m build (or uv build) and the build frontend, and uses setuptools as the build backend.

I've compared the sdists and wheels produced and the contain the same files, with the exception of now including 3 .sql that were previously excluded. Happy for that to be either way, it just happened by default since extra files in the package are now included by default, whereas in ye-olde times they weren't.

---

📚 Documentation preview 📚: https://datacube-core--1670.org.readthedocs.build/en/1670/

[pjonsson]

I think this is a great idea, is this PR something that could be merged to the 1.8 branch as well?

[SpacemanPaul]

No problems with this, but I need to understand why so many checks are failing.

Edit: the lint jobs are failing because pycodestyle and mypy are apparently not being installed. Presumably at least partly because the old tests dependency group is MIA - which probably also explains the actual test failures as well, although I haven't dug into them.

@pjonsson - in theory yes we could, but focus is very much on 1.9 branch at the moment, which we hope to release by the end of the year. After that, 1.8 development will mostly concentrate on bugfixes and making the upgrade to 1.9 smoother and easier. So in practice, it's unlikely to be a priority from our end. Always happy to review external PRs though.

[omad]

I think this is a great idea, is this PR something that could be merged to the 1.8 branch as well?
There's a couple of changed dependencies in 1.9... otherwise should be okay.

Edit: the lint jobs are failing because pycodestyle and mypy are apparently not being installed. Presumably at least partly because the old tests dependency group is MIA - which probably also explains the actual test failures as well, although I haven't dug into them.

I've moved the development/linting/test dependencies into dependency groups, defined in PEP 735 – Dependency Groups in pyproject.toml | peps.python.org.

I'll have a look at why CI is failing to install them. (Cursed CI)

[SpacemanPaul]

Passing tests now, but still failing the build action.

We can't really afford to let that break right now - unless you've got a fix waiting in another PR?

[omad]

I'm still working on it Paul.

Got scared seeing repeated segfaults in netcdf, so trying to work out how they started. I suspect there were tests not being run before, but I'm not sure.