Remove the _dev subpackage

[eerovaher]

Updated description

The version of pyerfa is not written down in pyproject.toml but is instead generated with setuptools_scm at build time. This works well for normal users, but developers working on pyerfa are very likely to install the code in editable mode, which avoids the need to rebuild the package after every code change and therefore also skips generating a new version identifier. The _dev subpackage is meant to provide updated version identifiers at runtime, but that subpackage relies on setuptools_scm, which is just a build dependency and therefore not likely to be installed even in a development environment. This means that pyerfa is very likely to report an outdated version identifier despite all the code in _dev, as demonstrated by the examples in the original description.

In this PR I am moving the code in _dev that checks the consistency of pyerfa and erfa versions to setup.py where it can be trusted to work because setup.py is executed by setuptools at build-time, so setuptools_scm will be available. I am removing everything else related to _dev.

If setuptools_scm does happen to be installed then it can be invoked directly with python -m setuptools_scm, which does produce the correct output unless there has been a new erfa release since the last pyerfa release. That is a rare enough occurrence that keeping _dev around just for that is not worthwhile.

Original description

The version of pyerfa is not written down in pyproject.toml but is instead generated with setuptools_scm at build time. This works well for normal users, but developers working on pyerfa are very likely to install the code in editable mode, which avoids the need to rebuild the package after every code change and therefore also skips generating a new version identifier. The _dev subpackage is meant to provide updated version identifiers at runtime, but that subpackage relies on setuptools_scm, which is just a build dependency and therefore not likely to be installed even in a development environment. This means that pyerfa is very likely to report an outdated version identifier despite all the code in _dev. Consider the following shell session as an example:

$ git rev-parse @
04807082d4fbace9b1ca5bae89ca28516fa08842
$ uv pip install --quiet --editable .
$ python -c 'from erfa.version import version; print(version)'
2.0.1.7.dev79+g04807082d
$ git switch --detach --quiet @~
$ git rev-parse @
6dc840c62bfc06c1099f21a59283774415f52d74
$ python -c 'from erfa.version import version; print(version)'
2.0.1.7.dev79+g04807082d

So all the code in _dev has achieved exactly nothing. Explicitly installing setuptools_scm allows _dev to function as intended, but also makes it emit a warning:

$ uv pip install --quiet setuptools-scm
$ python -c 'from erfa.version import version; print(version)'
.../erfa/_dev/scm_version.py:20: UserWarning: liberfa/erfa not at a tagged release, but at <ScmVersion 2.0.1 dist=6 node=g1d9738bed9954188722f976774d0903e5dae1857 dirty=False branch=HEAD>
  warn(f'liberfa/erfa not at a tagged release, but at {erfa_version}')
2.0.1.7.dev77+g6dc840c62

But if setuptools_scm is installed it can be invoked directly:

$ python -m setuptools_scm 
2.0.1.7.dev77+g6dc840c62

Direct invocation does not need _dev at all:

$ git switch --quiet rm_dev 
$ git rev-parse @
f28d483ec342f39ff1ff0cac0d3198c8222796c6
$ python -m setuptools_scm 
2.0.1.7.dev80+gf28d483ec

And if setuptools_scm is not installed then trying to invoke it does not silently produce an outdated result like _dev does:

$ uv pip uninstall --quiet setuptools_scm
$ python -m setuptools_scm 
.../.venv/bin/python: No module named setuptools_scm

[neutrinoceros]

The _dev subpackage is meant to provide updated version identifiers at runtime, but that subpackage relies on setuptools_scm, which is just a build dependency and therefore not likely to be installed even in a development environment.

100% agree with this. IMO this module creates more confusion than it provides value, by at least one order of magniture.

[avalentino]

While I would love to get rid of the _dev sub-package, I have to say that, unfortunately, the provided patch does not replicate exactly the old behavior.

The point, and the source of the complication, is that we normally have a 3-digits version number fully aligned with the "C" erfa version, but, in case we need to do a wrapper only change, we need to add a fourth digit in our version number.

This is documented in

pyerfa/RELEASING.rst

Lines 36 to 48 in 0480708

	Then, use ``git tag`` to tag the release::
	git tag -m <version> <version>
	e.g::
	git tag -m v1.7.0 v1.7.0
	Here, the version number should generally be the same as that of
	the erfa library that is included (and you should make sure the
	git submodule ``liberfa/erfa`` is at the correct tag as well).
	If there is a need for just the wrappers to be updated, add a
	fourth number to the release (e.g., ``1.7.0.1``).

This logic is implemented in the _guess_next_dev function in the _dev sub-package.

If this is perceived as a big issue, I'm totally open to change the versioning scheme, as soon as all the @liberfa/pyerfa-maintainers agree.

In this case, by the way, I would also kindly ask to include in the PR an update of the pyerfa/RELEASING.rst document with a proposal for the new versioning scheme and release procedure.

[eerovaher]

I moved the implementation of erfa._dev.scm_version._guess_next_dev() to setup.py and deleted everything else related to _dev. This change does mean that if you do have setuptools_scm available at runtime (but why would you?) then the version pyerfa reports in a development environment is not automatically updated without reinstalling pyerfa. But if setuptools_scm is available then it can be invoked directly with python -m setuptools_scm, which works as expected unless there has been a new erfa release since the last pyerfa. In my opinion this one rare and inconsequential failure mode is not enough to justify keeping _dev.

[eerovaher]

@avalentino, have you looked at the updated PR?