Comments (17)
hroncok
commented on June 12, 2024
For the record, when we see a build failure in our build system:
DEBUG setuptools_scm.config file pyproject.toml
DEBUG setuptools_scm.entrypoints version_from_ep setuptools_scm.parse_scm in /builddir/build/BUILD/python-lazy-object-proxy-1.10.0
DEBUG setuptools_scm.discover looking for ep setuptools_scm.parse_scm in /builddir/build/BUILD/python-lazy-object-proxy-1.10.0
DEBUG setuptools_scm.entrypoints version_from_ep setuptools_scm.parse_scm_fallback in .
DEBUG setuptools_scm.discover looking for ep setuptools_scm.parse_scm_fallback in .
DEBUG setuptools_scm.discover found ep EntryPoint(name='pyproject.toml', value='setuptools_scm.fallbacks:fallback_version', group='setuptools_scm.parse_scm_fallback') in .
DEBUG setuptools_scm.entrypoints EntryPoint(name='pyproject.toml', value='setuptools_scm.fallbacks:fallback_version', group='setuptools_scm.parse_scm_fallback') found None
DEBUG setuptools_scm.discover found ep EntryPoint(name='setup.py', value='setuptools_scm.fallbacks:fallback_version', group='setuptools_scm.parse_scm_fallback') in .
DEBUG setuptools_scm.entrypoints EntryPoint(name='setup.py', value='setuptools_scm.fallbacks:fallback_version', group='setuptools_scm.parse_scm_fallback') found None
DEBUG setuptools_scm.config check absolute root=. relative_to=pyproject.toml
DEBUG setuptools_scm.config file pyproject.toml
While when it actually works in a different one:
DEBUG setuptools_scm.config file pyproject.toml
DEBUG setuptools_scm.entrypoints version_from_ep setuptools_scm.parse_scm in /builddir/build/BUILD/python-lazy-object-proxy-1.10.0
DEBUG setuptools_scm.discover looking for ep setuptools_scm.parse_scm in /builddir/build/BUILD/python-lazy-object-proxy-1.10.0
DEBUG setuptools_scm.entrypoints version_from_ep setuptools_scm.parse_scm_fallback in .
DEBUG setuptools_scm.discover looking for ep setuptools_scm.parse_scm_fallback in .
DEBUG setuptools_scm.discover found ep EntryPoint(name='pyproject.toml', value='setuptools_scm.fallbacks:fallback_version', group='setuptools_scm.parse_scm_fallback') in .
DEBUG setuptools_scm.fallbacks FALLBACK 1.10.0
INFO setuptools_scm.version version 1.10.0 -> 1.10.0
DEBUG setuptools_scm.entrypoints EntryPoint(name='pyproject.toml', value='setuptools_scm.fallbacks:fallback_version', group='setuptools_scm.parse_scm_fallback') found <ScmVersion 1.10.0 dist=0 node=None dirty=False branch=None>
The sources should be identical, so I suspect it's the order of files on the filesystem or similar thing we cannot affect.
from setuptools_scm.
RonnyPfannschmidt
commented on June 12, 2024
what versions of setuptools and setuptools_scm are involved
the empty table should be removed upstream
i also recommend setting the pretend version var explicitly
from setuptools_scm.
hroncok
commented on June 12, 2024
This is setuptools_scm 8.0.4 with setuptools 68.2.2 -- I can test with a newer one...
from setuptools_scm.
hroncok
commented on June 12, 2024
I was gonna say that setuptools-68.2.2 blows up and setuptools-69.0.3 works correctly, but no, it's just flaky.
from setuptools_scm.
hroncok
commented on June 12, 2024
I reproduced with Python 3.12.1 and:
Package Version
----------------- -------
packaging 23.2
pip 23.2.1
setuptools 69.0.3
setuptools-scm 8.0.4
typing_extensions 4.9.0
from setuptools_scm.
hroncok
commented on June 12, 2024
the empty table should be removed upstream
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.
i also recommend setting the pretend version var explicitly
We can definitively do that when we build the package, but nevertheless, if fallback_version is supposed to work, I guess we should figure out what's happening here, no?
from setuptools_scm.
RonnyPfannschmidt
commented on June 12, 2024
Ah wait, it never should hit fallbacks for GitHub tarballs
Use pypi sdists
from setuptools_scm.
hroncok
commented on June 12, 2024
Ah wait, it never should hit fallbacks for GitHub tarballs
Why not? It says "fallback". I am confused.
Use pypi sdists
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.
from setuptools_scm.
RonnyPfannschmidt
commented on June 12, 2024
The git archival filename of the project is incorrect, thus it's not found
So it's incorrect repo setup
from setuptools_scm.
hroncok
commented on June 12, 2024
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.
from setuptools_scm.
RonnyPfannschmidt
commented on June 12, 2024
The error is in the git repo
That Tag will never produce a viable tarball
from setuptools_scm.
hroncok
commented on June 12, 2024
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 .git-archival.txt I still have the same error. If I clone the repo and delete .git, I have the same error.
What is the meaning of fallback_version, if not the fallback version?
from setuptools_scm.
hroncok
commented on June 12, 2024
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:
- Why does this work sometimes (no sure when yet)?
- Why does this work when we delete pyproject.toml?
- Why does it not fallback to the fallback version?
from setuptools_scm.
hroncok
commented on June 12, 2024
This is the smallest reproducer I can come up with. Has no git involved whatsoever.
I only have 2 files:
$ cat pyproject.toml
[tool.setuptools_scm]
$ cat setup.py
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'],
)
I create a venv and install latest setuptools and setuptools_scm into it:
$ python3.12 -m venv venv
$ venv/bin/pip install setuptools_scm setuptools
...
Successfully installed packaging-23.2 setuptools-69.0.3 setuptools_scm-8.0.4 typing-extensions-4.9.0
It works:
$ venv/bin/python setup.py --version
...
1.10.0
Now let me uninstall and install setuptools again. This should make no difference:
$ venv/bin/pip uninstall setuptools
...
Successfully uninstalled setuptools-69.0.3
$ venv/bin/pip install setuptools
...
Successfully installed setuptools-69.0.3
Yet suddenly, it no longer works:
$ rm _version.py # optional step, does not change the outcome
$ venv/bin/python setup.py --version
...
Traceback (most recent call last):
File ".../scmscm/setup.py", line 3, in <module>
setup(
File ".../scmscm/venv/lib64/python3.12/site-packages/setuptools/__init__.py", line 103, in setup
return distutils.core.setup(**attrs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File ".../scmscm/venv/lib64/python3.12/site-packages/setuptools/_distutils/core.py", line 147, in setup
_setup_distribution = dist = klass(attrs)
^^^^^^^^^^^^
File ".../scmscm/venv/lib64/python3.12/site-packages/setuptools/dist.py", line 303, in __init__
_Distribution.__init__(self, dist_attrs)
File ".../scmscm/venv/lib64/python3.12/site-packages/setuptools/_distutils/dist.py", line 283, in __init__
self.finalize_options()
File ".../scmscm/venv/lib64/python3.12/site-packages/setuptools/dist.py", line 654, in finalize_options
ep(self)
File ".../scmscm/venv/lib64/python3.12/site-packages/setuptools_scm/_integration/setuptools.py", line 121, in infer_version
_assign_version(dist, config)
File ".../scmscm/venv/lib64/python3.12/site-packages/setuptools_scm/_integration/setuptools.py", line 56, in _assign_version
_version_missing(config)
File ".../scmscm/venv/lib64/python3.12/site-packages/setuptools_scm/_get_version_impl.py", line 112, in _version_missing
raise LookupError(
LookupError: setuptools-scm was unable to detect version for .../scmscm.
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.
For example, if you're using pip, instead of https://github.com/user/proj/archive/master.zip use git+https://github.com/user/proj.git#egg=proj
from setuptools_scm.
hroncok
commented on June 12, 2024
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 # breaksfrom setuptools_scm.
RonnyPfannschmidt
commented on June 12, 2024
That particular error is indeed unexpected
from setuptools_scm.
Related Issues (20)
- what are the available version_scheme HOT 4
- Add a `just-the-tag` version scheme HOT 12
- Be a smidge more error tolerant? HOT 2
- How to keep the version when changing tracked files? HOT 7
- documentation outdated? HOT 3
- Why is get_version at runtime deprecated? HOT 1
- setuptools_scm does not get the latest git tag HOT 5
- `AssertionError: assert main_version is not None` when `pyproject.toml` defines its own `version_schema` and provides its own callable. HOT 2
- setup(python_requires=">=3.9") seems not supported HOT 2
- 8.0.4 fails to install with Python 3.8/3.9 (but works fine with Python 3.10+) HOT 6
- 8.0.4 fails to build wheel on python 3.10 with gpep517 v15 HOT 3
- Docs request: `SETUPTOOLS_SCM_PRETEND_VERSION` recommendation HOT 4
- SETUPTOOLS_SCM_PRETEND_VERSION not working when .hg folder does not exist HOT 6
- Failing to point to project's root HOT 2
- change env var variable name to something more comprehensble than NORMALIZED_DIST_NAME
- Provide more guidance on how to use `.git_archival.txt`
- on windows, path comparison should be case-insensitive HOT 1
- listing git files failed on git repo HOT 5
- LookupError: setuptools-scm was unable to detect version for /app when project is used as a git submodule. HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from setuptools_scm.