setuptools_scm 7.1.0 test incomampatibility

[hroncok]

hello, I am updating setuptools_scm in Fedora to 7.1.0 and I found a problem in the tests of this project.

Reproduced locally with:

[hatch-vcs (master)]$ python3.11 -m venv venv
[hatch-vcs (master %)]$ . venv/bin/activate

(venv) [hatch-vcs (master %)]$ pip install hatch
...
(venv) [hatch-vcs (master %)]$ pip list
Package            Version
------------------ ---------
anyio              3.6.2
certifi            2022.12.7
cffi               1.15.1
click              8.1.3
commonmark         0.9.1
cryptography       38.0.4
distlib            0.3.6
editables          0.3
filelock           3.8.2
h11                0.14.0
hatch              1.6.3
hatchling          1.11.1
httpcore           0.16.2
httpx              0.23.1
hyperlink          21.0.0
idna               3.4
importlib-metadata 5.2.0
jaraco.classes     3.2.3
jeepney            0.8.0
keyring            23.13.1
more-itertools     9.0.0
packaging          22.0
pathspec           0.10.3
pexpect            4.8.0
pip                21.2.3
platformdirs       2.6.0
pluggy             1.0.0
ptyprocess         0.7.0
pycparser          2.21
Pygments           2.13.0
pyperclip          1.8.2
rfc3986            1.5.0
rich               12.6.0
SecretStorage      3.3.3
setuptools         57.4.0
shellingham        1.5.0
sniffio            1.3.0
tomli_w            1.0.0
tomlkit            0.11.6
userpath           1.8.0
virtualenv         20.17.1
zipp               3.11.0

(venv) [hatch-vcs (master %)]$ hatch run cov
Checking dependencies
cmd [1] | coverage run -m pytest tests
============================= test session starts ==============================
platform linux -- Python 3.11.1, pytest-7.2.0, pluggy-1.0.0
rootdir: .../hatch-vcs
collected 22 items

tests/test_build.py .F...                                                [ 22%]
tests/test_build_config.py ......                                        [ 50%]
tests/test_metadata_config.py ....                                       [ 68%]
tests/test_version_config.py .......                                     [100%]

=================================== FAILURES ===================================
__________________________________ test_write __________________________________

new_project_write = '/tmp/tmpqtu8s2mv/my-app'

    def test_write(new_project_write):
        build_project('-t', 'wheel')

        build_dir = os.path.join(new_project_write, 'dist')
        assert os.path.isdir(build_dir)

        artifacts = os.listdir(build_dir)
        assert len(artifacts) == 1
        wheel_file = artifacts[0]

        assert wheel_file == 'my_app-1.2.3-py2.py3-none-any.whl'

        extraction_directory = os.path.join(os.path.dirname(new_project_write), '_archive')
        os.mkdir(extraction_directory)

        with zipfile.ZipFile(os.path.join(build_dir, wheel_file), 'r') as zip_archive:
            zip_archive.extractall(extraction_directory)

        metadata_directory = os.path.join(extraction_directory, 'my_app-1.2.3.dist-info')
        assert os.path.isdir(metadata_directory)

        package_directory = os.path.join(extraction_directory, 'my_app')
        assert os.path.isdir(package_directory)
        assert len(os.listdir(package_directory)) == 5

        assert os.path.isfile(os.path.join(package_directory, '__init__.py'))
        assert os.path.isfile(os.path.join(package_directory, 'foo.py'))
        assert os.path.isfile(os.path.join(package_directory, 'bar.py'))
        assert os.path.isfile(os.path.join(package_directory, 'baz.py'))

        version_file = os.path.join(package_directory, '_version.py')
        assert os.path.isfile(version_file)

        lines = read_file(version_file).splitlines()
>       assert lines[3].startswith(('version =', '__version__ ='))
E       AssertionError: assert False
E        +  where False = <built-in method startswith of str object at 0x7fd46bb624f0>(('version =', '__version__ ='))
E        +    where <built-in method startswith of str object at 0x7fd46bb624f0> = '__version_tuple__ = version_tuple = (1, 2, 3)'.startswith

.../hatch-vcs/tests/test_build.py:78: AssertionError
=========================== short test summary info ============================
FAILED tests/test_build.py::test_write - AssertionError: assert False
========================= 1 failed, 21 passed in 0.70s =========================

[hroncok]

(venv) [hatch-vcs (master %)]$ ~/.local/share/hatch/env/virtual/hatch-vcs/oGrlL7N9/hatch-vcs/bin/pip list
Package           Version Editable project location
----------------- ------- ------------------------------------
attrs             22.1.0
coverage          7.0.0
editables         0.3
hatch-vcs         0.3.0   .../hatch-vcs
hatchling         1.11.1
iniconfig         1.1.1
packaging         22.0
pathspec          0.10.3
pip               22.3.1
pluggy            1.0.0
pytest            7.2.0
setuptools        65.6.3
setuptools-scm    7.1.0
typing_extensions 4.4.0
wheel             0.38.4

[RonnyPfannschmidt]

this may be a issue in hatch/hatchling - hatch explicitly does not use setuptools_scm version hooks, i gotta check whats going on

[RonnyPfannschmidt]

ok, its a upstream issue - the template in setuptools_scm changed , while the api is compatible, the file contents aint

[hroncok]

while the api is compatible, the file contents ain't

Do I understand correctly that while the test fail, hatch-vcs still works as expected?

[musicinmybrain]

while the api is compatible, the file contents ain't

Do I understand correctly that while the test fail, hatch-vcs still works as expected?

One would have to look at the actual contents of the generated _version.py to be sure, but this is almost certainly true. The test makes assumptions about the exact text of the generated file, which makes it brittle. It has already needed adjustment once before (https://github.com/ofek/hatch-vcs/issues/8, https://github.com/ofek/hatch-vcs/pull/9).

[RonnyPfannschmidt]

@hroncok its highly likely to just work

[musicinmybrain]

The contents of the generated _version.py with setuptools_scm 7.1 are:

# file generated by setuptools_scm
# don't change, don't track in version control
__version__ = version = '1.2.3'
__version_tuple__ = version_tuple = (1, 2, 3)

So assert lines[3].startswith(('version =', '__version__ =')) could perhaps be changed to assert any(line.startswith(('version =', '__version__ =') for line in lines). What do you think?

It’s still a little brittle, but it should at least accommodate the current template and the known previous templates, and it seems like it has a good chance of not immediately breaking again. It does produce a less-helpful message if it breaks, though.