I have been struggling to get some software packaged that relies on setuptools_scm. It seems to effectively ignore the package data section in a pyproject.toml file and to include a broader collection of files when being
Which source package is this?
Where did the source come from? Git or PyPI tarball?
setuptools_scm gets stuff from SCM and uses it for metadata. During the package build, the SCM isn't available (no .git directory in the source package). So, it falls back to alternate modes:
1. The version gets put in an environment variable by pybuild.
2. The list of known files comes from the SOURCES.txt in egg-info. If
you are using the upstream git for your source, you may be missing
this. Try switching to a PyPI sdist.
The weird thing is that I can run "python3 -m build", even with the options that pybuild introduces, outside the gbp buildpackage environment, and it seems that the package data is obtained using setuptools_scm. But as part of the gbp invocation, the package data is limited to that mentioned in the deficient pyproject.toml file.
I have been struggling to get some software packaged that relies on setuptools_scm. It seems to effectively ignore the package data section in a pyproject.toml file and to include a broader collection of files when being
Which source package is this?
Where did the source come from? Git or PyPI tarball?
setuptools_scm gets stuff from SCM and uses it for metadata. During the package build, the SCM isn't available (no .git directory in the source package). So, it falls back to alternate modes:
1. The version gets put in an environment variable by pybuild.
2. The list of known files comes from the SOURCES.txt in egg-info. If
you are using the upstream git for your source, you may be missing
this. Try switching to a PyPI sdist.
Hi Paul (2024.07.12_00:05:03_+0000)
The weird thing is that I can run "python3 -m build", even with the
options that pybuild introduces, outside the gbp buildpackage environment, and it seems that the package data is obtained using setuptools_scm. But
as part of the gbp invocation, the package data is limited to that mentioned in the deficient pyproject.toml file.
Is your packaging in git? It'll be finding the list of files tracked by
git, from git.
The packaging is in git, yes. I suppose what I don't understand is the role of
setuptools_scm in building a package for installation (or the construction of
a binary package). A source package will aim to incorporate all of the tracked
files, but a built/binary package may not.
The way to deal with it, is simply something like this:
export SETUPTOOLS_SCM_PRETEND_VERSION=$(shell dpkg-parsechangelog -SVersion
| sed -e 's/^[[:digit:]]*://' -e 's/[-].*//' -e 's/~git.*//' -e 's/~/.0/' -e 's/+dfsg1//' -e 's/+ds1//' | head -n 1)
and then setuptools-scm knows what version to use without using the Git history.
Probably pybuild does that automatically under the hood (I tend to not use pybuild, and so I do the above ...).
Hi Thomas (2024.07.12_12:53:54_+0000)
The way to deal with it, is simply something like this:
export SETUPTOOLS_SCM_PRETEND_VERSION=$(shell dpkg-parsechangelog -SVersion | sed -e 's/^[[:digit:]]*://' -e 's/[-].*//' -e 's/~git.*//' -e 's/~/.0/' -e
's/+dfsg1//' -e 's/+ds1//' | head -n 1)
and then setuptools-scm knows what version to use without using the Git history.
Probably pybuild does that automatically under the hood (I tend to not use pybuild, and so I do the above ...).
It does.
I had a similar problem when setuptools_scm kicked in during the build process
and produced versions different from the orig tarball. Packaging is in git and
tarballs are imported from PyPI.
I disabled the automatic versioning with
https://salsa.debian.org/tryton-team/python-csb43/-/commit/e8788e09818948231a48cc1472a5f54444b65fcc
Could you confirm this is the right approach or is there a more elegant way?
I have no clue why this is working for you.
I removed the patch, tried your proposal and the build just fails because setuptools-scm writes again a dev version to src/csb43/_version.py:
https://salsa.debian.org/tryton-team/python-csb43/-/jobs/5988081
dpkg-source: info: local changes detected, the modified files are:
source_dir/src/csb43/_version.py
I had a similar problem when setuptools_scm kicked in during the build process and produced versions different from the orig tarball. Packaging is in git and tarballs are imported from PyPI.
I disabled the automatic versioning with
https://salsa.debian.org/tryton-team/python-csb43/-/commit/e8788e09818948231a48cc1472a5f54444b65fcc
Could you confirm this is the right approach or is there a more elegant way?
That approach doesn't look great.
Instead of that patch, just Build-Depend on python3-setuptools-cm, so
that it can do its magic. In my testing it works just fine on your
package.
Oh, you're also missing pytest, so the package tests are failing.
I have no clue why this is working for you.
I removed the patch, tried your proposal and the build just fails because setuptools-scm writes again a dev version to src/csb43/_version.py:
But SETUPTOOLS_SCM_PRETEND_VERSION like proposed by Thomas did the trick. https://salsa.debian.org/tryton-team/python-csb43/-/pipelines/703025...
May be pybuild doesn't handle correctly a version string like 0.10.0+dfsg-1?
[...]
May be pybuild doesn't handle correctly a version string like 0.10.0+dfsg-1?
Yeah, you shouldn't have to export that because pybuild does. But,
right, it's not removing +dfsg. Now that PEP-440 versions are strongly enforced, that's no good.
Committed: https://salsa.debian.org/python-team/tools/dh-python/-/commit/ae0facfd1216fd25185aa5f1db9f12b26e3dbcf1
On Fri, Jul 19, 2024 at 11:06:46AM +0000, Stefano Rivera wrote:
[...]
May be pybuild doesn't handle correctly a version string like 0.10.0+dfsg-1?
Yeah, you shouldn't have to export that because pybuild does. But,
right, it's not removing +dfsg. Now that PEP-440 versions are strongly enforced, that's no good.
Committed: https://salsa.debian.org/python-team/tools/dh-python/-/commit/ae0facfd1216fd25185aa5f1db9f12b26e3dbcf1
But PEP-440 allows "+dfsg" as the "Local version identifier", so I
don't understand why this must be removed.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 350 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 10:31:06 |
| Calls: | 7,625 |
| Files: | 12,793 |
| Messages: | 5,686,539 |