liberfa version number test too tight

[olebole]

On Debian, we have pyerfa and erfa in separate packages and update them independently (and by different people). However, there is one test that fails when doing so:

pyerfa/erfa/tests/test_erfa.py

Lines 37 to 43 in 822d095

	def test_version(self):
	assert hasattr(erfa, '__version__')
	version = erfa.__version__
	assert version is erfa.version.version
	# Oops, we had the wrong version for quite a while...
	assert (erfa.version.erfa_version == '1.6.0' and version.startswith('1.7.0')
	or version.startswith(erfa.version.erfa_version))

Specifically, I now updated erfa to 1.7.1, and pyerfa-1.7.0 fails on this test now. It would IMO be better if the test would just check the backward compatibility, i.e. that pyerfa uses a version that is too old (incompatible) with the current version. But in principle, if all other tests succeed (and have sufficient code coverage) there would be no need to have this test at all?

Having too strong dependencies on the package (even for testing) makes it much harder to maintain them.

Cc: @avalentino as the Debian maintainer of pyerfa

[bnavigator]

+1 from openSUSE

[bnavigator]

BTW, the last commit on master 822d095 makes the same fail even with bundled erfa 1.7.1

The test reveals a very confusing naming convention: How to distinguish between pyerfa version and erfa version? Unless you really want to pin to equal versions for both packages, the attributes should have a more declarative name. Otherwise a strict pin on the requirements and coincident releases would be needed. In that case, did you just forget to mark the tag https://github.com/liberfa/pyerfa/releases/tag/v1.7.1 as release and upload to PyPI?

[bnavigator]

According to #39 (comment), differing versions between liberfa and pyerfa should be okay. Skipping the test for now.

[avalentino]

In #53 the test have been changed to perform tight version checking only in case of embedded liberfa.