On 4/1/24 00:32, Stefano Rivera wrote:
So... for Python packages using setuptools-scm, we're pushed towards
depending on upstream-created source tarballs (sdists), rather than
upstream git archives, because we don't have the ".git" directory in our
source packages.

Hi Stefano,

Thanks for jumping in this thread, though I'll have to disagree with you... with all due respect! :)

As you know, I'm by far the biggest uploader of Python modules in Debian, due to the fact I'm maintaining OpenStack. As you may know as well, the reason I'm not maintaining all of that inside the Debian Python Team, is only because it's forbidden to use an upstream git tag workflow in the team, and that I have to use pristine-tar. I very much regret this fact, but live with it when I have to package within the Debian Python Team.

Anyways, on the 400+ packages that I maintain within the OpenStack team, I did come across some upstream using setuptools-scm. To my experience, using the:

git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \
        | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz

workflow out of an upstream always work, including for those that are using setuptools-scm. One simply needs to add the dependency, and correctly set, with something like this:

SETUPTOOLS_SCM_PRETEND_VERSION=$(shell dpkg-parsechangelog -SVersion \
        | sed -e 's/^[[:digit:]]*://' \
        -e 's/[-].*//' \
        -e 's/~/.0/' \
        -e 's/+dfsg1//' \
        | head -n 1)

Because I'm dealing with the DPT packages as well, I can tell, and I insist: the workflow to to work with upstream Git is a way nicer than the pristine-tar / gbp import-orig one. The upstream tag workflow *ALWAYS* work, and often (even: always, for the case of Python modules) contain less pre-built artifacts.

Also, sdists are *not* "upstream-created source tarballs". I consider the binary form built for PyPi. Just like we have .debs, PyPi has tarballs and wheels, rather than how you describe them.

By the way, am I the only one to think that's so lame to use tarballs in so many ways... Isn't this a so ... legacy retro-computing format? :)

Cheers,

Thomas Goirand (zigo)

Reply via email to