build: move to pyproject

[gampnico]

New features:

• Refactors installation to use pyproject instead of setuptools.
  • Install OGGM and its relevant dependencies with pip, conda, or uv (no more .yaml files).
• Adds support for uv.
  - Refactors installation documentation to reflect the new installation procedure. - separate PR

Todo:

• ensure dynamic versioning correctly reads from .git_archival when necessary.
• verify conda packaging.
  - [ ] document uv features new users may find useful. - separate PR

Closes #1774, #990, #1482, #1429, #1395, #620, #1416, #883.

• Tests added/passed
  - [ ] Fully documented - separate PR
• Entry in whats-new.rst

[fmaussion]

Thanks @gampnico ! I will need a bit of time to get clever about this. In the meantime, can you remove the doc changes for now as I think this will require more thinking / testing.this should focus on the changes to pyproject first

[TimoRoth]

How does it derive the version number exactly?
setuptools-scm looks at the .git_archival.txt file when possible. I can't immediately find much info on uv_builds dynamic versioning tool also doing that.
If it doesn't, installation from a tarball downloaded from github will not work properly.

[gampnico]

How does it derive the version number exactly? setuptools-scm looks at the .git_archival.txt file when possible. I can't immediately find much info on uv_builds dynamic versioning tool also doing that. If it doesn't, installation from a tarball downloaded from github will not work properly.

After some discussion with @fmaussion, I'm going to rewrite this so hatchling is the default build backend, with hatch-vcs set to emulate setuptools' previous behaviour.

[gampnico]

Linking ofek/hatch-vcs#72 just in case it also affects us.

[fmaussion]

Currently 3 files in MANIFEST that need shipping - the others I've deleted in recent PR

[TimoRoth]

What I still have trouble finding info on is if hatch-vcs uses .git_archival.txt to get version info.
Its documentation does not say anything about it. But if I pip install https://github.com/gampnico/oggm/archive/refs/heads/refactor-uv-installation.zip in a test venv, it versions it as oggm-1.6.3.dev64+gada4b03f8, which is strange, since it's the correct commit hash, and the correct offset, but the version number is wrong, since it should be 1.6.2, as git archival says v1.6.2-64-gada4b03f8.
Given the commit hash is nowhere else to be found in that archive except in the archival file, it must at least be looking at it.

Otherwise, this looks good to me.

Edit:
Oh, hatch-vcs literally calls out to setuptools_scm:
https://github.com/ofek/hatch-vcs/blob/master/hatch_vcs/version_source.py#L69

So our existing setuptools_scm compatible git archival file will keep working as it is.

[gampnico]

What I still have trouble finding info on is if hatch-vcs uses .git_archival.txt to get version info.
Its documentation does not say anything about it. But if I pip install https://github.com/gampnico/oggm/archive/refs/heads/refactor-uv-installation.zip in a test venv, it versions it as oggm-1.6.3.dev64+gada4b03f8, which is strange, since it's the correct commit hash, and the correct offset, but the version number is wrong, since it should be 1.6.2, as git archival says v1.6.2-64-gada4b03f8.
Given the commit hash is nowhere else to be found in that archive except in the archival file, it must at least be looking at it.

Otherwise, this looks good to me.

Edit:
Oh, hatch-vcs literally calls out to setuptools_scm:
https://github.com/ofek/hatch-vcs/blob/master/hatch_vcs/version_source.py#L69

So our existing setuptools_scm compatible git archival file will keep working as it is.

Thanks for trying it out @TimoRoth. Hatch VCS has a setting to decrement the generated version number, so I will change this.

[gampnico]

On the subject of pins, @TimoRoth would you like me to use the pins you've set in the Dockerfile?

[fmaussion]

I'd prefer as few pins as possible in this file. The docker images and this here have different purposes

[TimoRoth]

On the subject of pins, @TimoRoth would you like me to use the pins you've set in the Dockerfile?

That's not a Dockerfile? Is this the right link, or did you mean the Anaconda-Recipe?
Neither the Dockerfile in https://github.com/OGGM/OGGM-Docker/ nor the Anaconda-Recipes contain any pins though, only minimum versions for a few packages, that should be mostly irrelevant nowadays since they're years old and should always be fulfilled.

Since those repos run automatic CI we notice breakages as they happen, and try to fix them.

[gampnico]

That's not a Dockerfile? Is this the right link, or did you mean the Anaconda-Recipe? Neither the Dockerfile in https://github.com/OGGM/OGGM-Docker/ nor the Anaconda-Recipes contain any pins though, only minimum versions for a few packages, that should be mostly irrelevant nowadays since they're years old and should always be fulfilled.

Sorry, yes I meant the recipe. Thanks for the info.

[TimoRoth]

There is no pypi release of our pytest-mpl fork, so probably needs to have the direct github URL there.

[gampnico]

There is no pypi release of our pytest-mpl fork, so probably needs to have the direct github URL there.

It was released last Friday. Direct references aren't allowed for PyPI packages.

[TimoRoth]

There is no pypi release of our pytest-mpl fork, so probably needs to have the direct github URL there.

It was released last Friday. Direct references aren't allowed for PyPI packages.

Is this self-managing, and just pulls from the git repo?
I thought pypi was only manual and signed package uploads?

[gampnico]

I did this manually. PyPI does accept CI uploads, but this failed for pytest-mpl-oggm as I didn't set the necessary authorisation.

[fmaussion]

Let's try this for a while before release!