LookupError: setuptools-scm was unable to detect version if [tool.setuptools_scm] is in pyproject.toml #1011
Comments
|
For the record, when we see a build failure in our build system: While when it actually works in a different one: The sources should be identical, so I suspect it's the order of files on the filesystem or similar thing we cannot affect. |
|
what versions of setuptools and setuptools_scm are involved the empty table should be removed upstream |
|
This is setuptools_scm 8.0.4 with setuptools 68.2.2 -- I can test with a newer one... |
|
I was gonna say that setuptools-68.2.2 blows up and setuptools-69.0.3 works correctly, but no, it's just flaky. |
|
I reproduced with Python 3.12.1 and: |
I don't know why they have that. It being empty makes me feel uncomfortable as well. However, at least it should error explicitly or behave consistently if that is the problem.
We can definitively do that when we build the package, but nevertheless, if |
|
Ah wait, it never should hit fallbacks for GitHub tarballs Use pypi sdists |
Why not? It says "fallback". I am confused.
To clarify: we have a workaround available, we are not trying to sort out how to do this, we are trying to figure out what's going on here. |
|
The git archival filename of the project is incorrect, thus it's not found So it's incorrect repo setup |
|
What does "git archival filename of the project" mean? This happens on unpackaged tarball. If I rename the directory to lazy-object-proxy-1.10.0 it still happens. |
|
The error is in the git repo That Tag will never produce a viable tarball |
|
I am sorry. I have no idea what you mean. There is a fallback version set. Sometimes, it is respected, sometimes it is not. I have no idea yet why. If I delete What is the meaning of fallback_version, if not the fallback version? |
|
For the record, the error does indeed tell me that what I do is wrong: "Make sure you're either building from a fully intact git repository or PyPI tarballs. Most other sources (such as GitHub's tarballs, a git checkout without the .git folder) don't contain the necessary metadata and will not work." However, things I don't understand:
|
|
This is the smallest reproducer I can come up with. Has no git involved whatsoever. I only have 2 files: I create a venv and install latest setuptools and setuptools_scm into it: It works: Now let me uninstall and install setuptools again. This should make no difference: Yet suddenly, it no longer works: |
|
A script: cat > pyproject.toml << EOF
[tool.setuptools_scm]
EOF
cat > setup.py << EOF
from setuptools import setup
setup(
name='xxx',
use_scm_version={
'local_scheme': 'dirty-tag',
'write_to': '_version.py',
'fallback_version': '1.10.0',
},
setup_requires=['setuptools_scm'],
)
EOF
python3.12 -m venv venv
venv/bin/pip install -Uq setuptools_scm setuptools
venv/bin/python setup.py --version # works
venv/bin/pip uninstall -qy setuptools
venv/bin/pip install -q setuptools
venv/bin/python setup.py --version # breaks |
|
That particular error is indeed unexpected |
|
@hroncok thanks for that minimal repro case - I've been investigating a similar problem with the I believe the unpredictable behaviour is likely to be from the same cause, and that it relates to the order that the Findings (so far)Both the In the case of The Although the Issue #1022 seems to relate to this area too. Observations / possible solutionsWhat I find locally following installation of I do think that the nondeterminism could be mitigated somewhere around the |
- Add a pre-test stage that adds a [tool.setuptools_scm] section to
project.toml, so that tests can detect the version.
Otherwise 5 tests fail with an error similar to
________________________________________________________________________________________________________________________ test_fail_no_traceback ________________________________________________________________________________________________________________________
raise_on_session_done = <function raise_on_session_done.<locals>._func at 0x3f63e7392c10>, tmp_path = PosixPath(/tmp/pytest-of-root/pytest-5/test_fail_no_traceback0), capsys = <_pytest.capture.CaptureFixture object at 0x3f63e5c0aca0>
def test_fail_no_traceback(raise_on_session_done, tmp_path, capsys):
raise_on_session_done(ProcessCallFailedError(code=2, out="out\n", err="err\n", cmd=["something"]))
with pytest.raises(SystemExit) as context:
run_with_catch([str(tmp_path)])
assert context.value.code == 2
out, err = capsys.readouterr()
assert out == f"subprocess call failed for [{something!r}] with code 2\nout\nSystemExit: 2\n"
> assert err == "err\n"
E AssertionError: assert ... nerrn == errn
E + WARNING pyproject.toml does not contain a setuptools.py:119
E + tool.setuptools_scm section
E err
tests/unit/config/test___main__.py:52: AssertionError
See also pypa/setuptools_scm#1011
Release changes: https://github.com/pypa/virtualenv/releases/tag/20.26.0
Reported by: Bernát Gábor <notifications@github.com>
project: https://github.com/ionelmc/python-lazy-object-proxy/
download the source code, extract the tar archive and enter the folder: https://github.com/ionelmc/python-lazy-object-proxy/archive/refs/tags/v1.10.0.tar.gz
In pyproject.toml there is empty table
[tool.setuptools_scm]defined.In setup.py you can find the
use_scm_versionkeyword argument withfallback_versionexplicitly defined.Running
SETUPTOOLS_SCM_DEBUG=1 python setup.py --versionends up with a LookupError:I comment out the [tool.setuptools_scm] table and run
SETUPTOOLS_SCM_DEBUG=1 python setup.py --versionagain.No error. Version is correctly set. Please note the found EntryPoint name set to pyproject.toml while in fact all this data is read from setup.py:
We came across this issue while debugging a weird behavior of two Fedora's build tools: copr, where the build consistently fails and locally in mock with exactly the same environment, where no such issue arises, the version is read correctly. Could it be that the mere order in which files are read creates such discrepancies?
The text was updated successfully, but these errors were encountered: