MNT: add static configuration for setuptools-scm

[neutrinoceros]

Address #165

[neutrinoceros]

good news, it looks like we can actually reproduce the real error on this repo now: https://github.com/liberfa/pyerfa/actions/runs/12963097535/job/36160295587

[neutrinoceros]

The build error on aarch64 is unrelated. See upstream issue at tonistiigi/binfmt#215

[pllim]

Is it also possible to clean up setup.py version stuff? Do we really need guess next version?

[neutrinoceros]

Oh I missed that part. I was assuming that setuptools-scm was relying on some default behavior but it actually is all done dynamically... you're right, I do need to address this in the same PR !

Do we really need guess next version?

Indeed we shouldn't need this. I'm guessing it was done to support building without setuptools-scm available 4 years ago (65603bd)

[pllim]

There's also a version.py but it's probably ok as is. Second pair of eyes won't hurt. Thanks!

[mhvk]

This looks good but as I don't remember quite why we had the fairly complicated code in setup.py, I've requested a review from @avalentino.

[mhvk]

p.s. Thanks for linking to the upstream issue with aarch64.

[avalentino]

Dear @neutrinoceros , @pllim , @mhvk ,
I fear that not using a proper guess_next_dev function in setup.py would break the version scheme described in RELEASING.rst (that is also enforced in some of the tests).
Even if no tests fails right now, I fear that we would have failures at the next update of the C liberfa version.

According to my understanding you want to have

[tool.setuptools_scm]
version_file = "erfa/_version.py"

in the pyproject.toml file.
IMHO this is still possible without dropping also

use_scm_version = {
    'version_scheme': guess_next_dev,
}

from setup.py.
By the way, I would be in favour of a simplification of the current setuptools-scm machinery, and I would be open to discuss a change in the versioning scheme if you want to propose something,

[neutrinoceros]

Thanks @avalentino for your quick review !
I reverted most of the changes in setup.py, now this PR is only about moving the deprecated write_to option to pyproject.toml and replacing it with it's not-deprecated equivalent. I checked that setuptools-scm knows how to combine static and dynamic configuration options by setting version_file = "erfa/_version_test.py" and inspecting build artifacts.

[avalentino]

Thanks @neutrinoceros

[pllim]

Thanks all!

[pllim]

A release soon would be nice so the "exotic" job can pick it up. We don't run those jobs on dev pyerfa.

[pllim]

Actually how does python3-erfa gets pushed to ubuntu-rolling?

https://github.com/astropy/astropy/blob/a1679d163d63d29b732e8e904118e1bf67e072d0/.github/workflows/ci_cron_weekly.yml#L149

[mhvk]

OK, I'm making a new release. I think the release gets into ubuntu-rolling via Debian, i.e., really via @olebole.

p.s. I guess the wheels built will fail for aarch64...

[mhvk]

Hmm, the aarch64 failure also causes the wheel building generally to be aborted, so I cannot really release the wheels. I could do a github source release, but am not sure that is useful...

[pllim]

Hmm is it possible to opt out of aarch64 wheel for this release?

[avalentino]

OK, I'm making a new release. I think the release gets into ubuntu-rolling via Debian, i.e., really via @olebole.

p.s. I guess the wheels built will fail for aarch64...

I can help for the debian part. Once the release is ready I can quickly push the new version in debian