On Thu, Jul 04, 2024 at 08:21:55PM +0200, Étienne Mollier wrote:
> Hi Julian,
>
> Julian Gilbey, on 2024-07-03:
> > Is there any chance that setting SETUPTOOLS_SCM_PRETEND_VERSION would
> > help?
>
> Thanks for the hint, it sounded worth a try and I started a
> build, including in d/rules:
>
> include /usr/share/dpkg/pkg-info.mk
> export SETUPTOOLS_SCM_PRETEND_VERSION = $(DEB_VERSION_UPSTREAM)
>
> but early build steps tripped on 0+unknown anyway:
>
> […]
> UPDATING build/lib/distributed/_version.py
> set build/lib/distributed/_version.py to '0+unknown'
> […]
>
> Version handling looks to originate from distributed/_version.py
> which in turn is supposed to have been autogenerated somehow by
> versionneer. Worst case scenario, I suppose it could be
> possible to hardwire the package version at the following
> location:
Ah! Have a look at what I used to do with debugpy (version 1.8.0+ds-*
for example): I deleted _version.py from the source file (in
debian/copyright) and reintroduced it via a patch
(pypi-version.patch), taking the _version.py file from the PyPI
distribution. I checked that the patch was up-to-date in
debian/rules (as it was easy to forget), using the following lines:
include /usr/share/dpkg/pkg-info.mk
UPSTREAM_VERSION = $(subst +ds,,$(DEB_VERSION_UPSTREAM))
execute_after_dh_testdir:
grep -q $(UPSTREAM_VERSION) src/debugpy/_version.py
I noticed that in more recent versions of debugpy, the _version.py
file in git actually works fine - it was generated upstream by
versioneer.py version 0.23, but if it doesn't, the above seems to
work.
Best wishes,
Julian
