On Wed, Feb 11, 2026 at 08:52:04PM +0100, Simon Josefsson wrote:
The Python Team's Policy insistance on use of pristine-tar and throwing
away upstream git history is [1]:
DPT requires a pristine-tar branch, and only upstream tarballs can be
used to advance the upstream branch. Complete upstream Git history
should be avoided in the upstream branch.
Well, for my own packages I insist on including upstream git history, so
this certainly wasn't my choice, and it was before my time on the DPT.
However, I suspect that it was a pragmatic choice to make it even
slightly practical to maintain several thousand source packages in a
more or less uniform structure despite the upstreams using a pretty wide
variety of code hosting mechanisms and practices. IIRC there are still
quite a few packages that use something other than git or that have no
public git repository, and there are definitely plenty where the
upstream maintainer seems to pay more attention to what's on PyPI than
what they've tagged in git (e.g. they don't bother to push tags). The
big popular packages usually work the way you'd expect, but there is a
significant long tail.
We already have an almost impossible amount of work to do just keeping
up with ecosystem-wide changes (sure, there's been nothing even remotely
on the scale of the Python 3 transition for a long time, but small
probabilities of being affected by any given breaking change multiplied
by thousands of packages still mount up quickly). Despite understanding
the downsides of the current team policy, I for one have absolutely no
appetite or capacity for yet another thing that requires us to go around
and reorganize everything. dgit/tag2upload doesn't require us to do
that; it can slot into our existing workflows, and not all team members
even have to agree.
The pypi.debian.net man-in-the-middle upstream tarball redirector is the
recommended (?) debian/watch URL to use for Python packages [2].
We've been gradually moving away from this in some cases in favour of
pointing to forge-generated tarballs, but it varies somewhat. There is
no one approach that works for all Python packages:
* Source distributions ("sdists") pushed to PyPI are technically a
build product of the upstream source tree, and sometimes they don't
include all the files we need - for example, omitting tests is fairly
common, as is trying to include tests but omitting some of the data
files they need. And some upstreams only publish wheels to PyPI and
not sdists.
* On the other hand, it's also fairly common to run into packages where
upstream uses something like submodules, and so the forge-generated
tarballs will be incomplete and basically useless. So will pointing
directly to upstream git tags unless you mess about with multiple
components. In those cases the sdists on PyPI usually work fine and
are much less hassle.
So sure, the situation is not ideal. But it might be worth walking a
mile in our shoes first.
--
Colin Watson (he/him) [[email protected]]
