Version file is not generated since version 8 on CI without any error

[Czaki]

Since setuptools_scm release 8 I have observed a test crash because the version file is not generated.

   /tmp/tox/py311-PyQt5-all/lib/python3.11/site-packages/PartSeg/__init__.py:4: in <module>
      from PartSeg.version import version
  E   ModuleNotFoundError: No module named 'PartSeg.version'

When it is configured in pyproject.toml: https://github.com/4DNucleome/PartSeg/blob/bcaf0aad2e80edbf25e42859f8a0722074f0c68b/pyproject.toml#L1-L7

But when I pin setuptools_scm below 8 all problems disappear.

Here is log with SETUPTOOLS_SCM_DEBUG set to 1.
https://github.com/4DNucleome/PartSeg/actions/runs/6273817081/job/17038040421?pr=1020

I cannot reproduce it locally. I do not have any idea how to debug this.

[RonnyPfannschmidt]

what version of tox is being used - its possible a pip upgrade of setuptools is needed, im not sure i can debug this one before monday

[RonnyPfannschmidt]

for extra details, please let the build package build a wheel with output and SETUPTOOL_SCM_DEBUG=true

[RonnyPfannschmidt]

@Czaki it seems like the shallow git checkout is trubling etuptools_scm

the .pkg workflow of tox i not producing any debug output either, so a lot is missing

[Czaki]

what version of tox is being used

tox 4.11.3
setuptools 65.5.0

Build wheel and sdist (no version.py file) package22.zip

Logs from build package: Build package.zip

[Czaki]

@Czaki it seems like the shallow git checkout is trubling etuptools_scm

The build linked above uses fetch depth 0 (all history) and still version file is not attached, even if the version is properly determined in file name.

But in other project we got such errors "ERROR setuptools_scm._file_finders.git listing git files failed - pretending there aren't any" on windows ci but not have yet enough information for separate report.

[Czaki]

I pass wrong variable: SETUPTOOL_SCM_DEBUG instead of SETUPTOOLS_SCM_DEBUG

logs: Build package.zip
build output: package22.zip

EDIT. Also full repo history do not change the situation, and version.py file is absent.

[RonnyPfannschmidt]

the logs indicate lack of history (tus generating a wrong version) and indeed no logging of writing,

i'll need to debug this in detail

[Czaki]

Could I help somehow? Create log with full git history?

[RonnyPfannschmidt]

It seems i can replicate the issue using tox

More debugging is needed as to the cause

[RonnyPfannschmidt]

@Czaki i did a fresh local shallow clone and got version files correct, i suspect the tox setup is involved

[Czaki]

@Czaki i did a fresh local shallow clone and got version files correct, i suspect the tox setup is involved

but I attach output from CI where I do only clone and call python -m build and file is missed. In this job there is no tox.

  build_package:
    name: Build package
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 1
      - name: Set up Python 3.11
        uses: actions/setup-python@v4
        with:
          python-version: 3.11

      - name: Install dependencies
        run: |
          pip install -U build

      - name: Build package
        run: |
          python -m build --sdist --wheel .
        env:
          SETUPTOOLS_SCM_DEBUG: true

      - name: Upload package
        uses: actions/upload-artifact@v3
        with:
          name: package22
          path: dist
          retention-days: 5

Did you do shallow copy of this PR?
If yes then you need to remove <8 from pyproject.toml file the setuptools_scm constraints

[zzzeid]

Hello 👋

I am also getting a similar error, both in version 8 and in previous versions (tested on 7.1.0 and 8.0.3). It only started happening in the last few days, and it coincided with a new release of an Ubuntu 22.04 image (20230917.1.0, could be coincidental/unrelated) on GitHub Actions.

Example failed build (7.1.0): https://github.com/mozilla/mozregression/actions/runs/6240525450/job/17049062792.
Link to pyproject.toml: https://github.com/mozilla/mozregression/blob/main/pyproject.toml#L6

mozregression/__init__.py:1: in <module>
    from .version import version
E   ModuleNotFoundError: No module named 'mozregression.version'

Edit: Seems to affect most versions of Python (tested 3.7 to 3.11), and only on Ubuntu 22.04 and Windows for some reason. macOS and Ubuntu 20.04 appear to not be affected by this issue.

[RonnyPfannschmidt]

@zzzeid what setuptools version is made available - can you try what happens if setup_requires is removed?

[RonnyPfannschmidt]

@Czaki same to you, its possibly a regression in the setuptools integration that i missed (as typically use_scm_version and pyproject are not mixed deeply, i may need to expand the handling to correctly get all data

[zzzeid]

@zzzeid what setuptools version is made available

Seems like they all are using 68.0.0. I also checked the old build from last week that was successful, uses the same version.

Successful build (Python 3.9, Ubuntu 20.04): setuptools==68.0.0
Failed build (Python 3.10, Ubuntu 22.04): setuptools==68.0.0
Failed build (Python 3.11, Windows): setuptools==68.0.0
Successful build (Python 3.11, macOS): setuptools==68.0.0

can you try what happens if setup_requires is removed?

I will try that and let you know.

Edit: same error after removing setup_requires.

(sorry, realized that you can't see the detail on those runs, but the error is exactly the same, pasted below).

============================= test session starts ==============================
platform linux -- Python 3.8.18, pytest-7.4.2, pluggy-1.2.0
PySide6 6.5.1.1 -- Qt runtime 6.5.1 -- Qt compiled 6.5.1
rootdir: /home/runner/work/mozregression/mozregression
plugins: mock-3.11.1, qt-4.2.0
collected 0 items / 1 error

==================================== ERRORS ====================================
________________________ ERROR collecting test session _________________________
env/lib/python3.8/site-packages/_pytest/config/__init__.py:641: in _importconftest
    mod = import_path(conftestpath, mode=importmode, root=rootpath)
env/lib/python3.8/site-packages/_pytest/pathlib.py:567: in import_path
    importlib.import_module(module_name)
/opt/hostedtoolcache/Python/3.8.18/x64/lib/python3.8/importlib/__init__.py:127: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
<frozen importlib._bootstrap>:1014: in _gcd_import
    ???
<frozen importlib._bootstrap>:991: in _find_and_load
    ???
<frozen importlib._bootstrap>:975: in _find_and_load_unlocked
    ???
<frozen importlib._bootstrap>:671: in _load_unlocked
    ???
env/lib/python3.8/site-packages/_pytest/assertion/rewrite.py:178: in exec_module
    exec(co, module.__dict__)
tests/unit/conftest.py:3: in <module>
    from mozregression import build_range
mozregression/__init__.py:1: in <module>
    from mozregression.version import version
E   ModuleNotFoundError: No module named 'mozregression.version'
=========================== short test summary info ============================
ERROR  - ModuleNotFoundError: No module named 'mozregression.version'
!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!
=============================== 1 error in 0.57s ===============================
Error: Process completed with exit code 2.

[RonnyPfannschmidt]

Also please remove use_scm_version=True

[zzzeid]

Also please remove use_scm_version=True

That appears to get things working again! Will see if there are any other impacts but looks pretty good so far. Thanks!

[RonnyPfannschmidt]

I have a idea for a Bugfix now, Will get that done over the weekend

[Czaki]

It looks like use_scm_version=True fixes my case.

[zzzeid]

It is a deprecated feature and I could have noticed this sooner (https://github.com/pypa/setuptools_scm/tree/v7.1.0#setuppy-usage-deprecated). It would be interesting to see the root cause of the actual bug and why it didn't affect certain platforms, but that's not necessary per se. Thank again for the help!

[bnavigator]

The Slycot CI started to fail from this error as well.

We are using scikit-build (not scikit-build-core yet) and do have setup(use_scm_version=True) in setup.py

https://github.com/python-control/Slycot/actions/runs/6285374495/job/17067739674?pr=214

Removing the use_scm_version=True seems to help. I am not sure if that was needed for setuptools_scm < 8