On Thu, Nov 07, 2024 at 11:41:28AM +0100, Guillem Jover wrote: > On Thu, 2024-11-07 at 02:01:49 +0000, Colin Watson wrote: > > I'd initially misread it as being just a day or two after the yanked > > version, but you're right, it was months later. I suspect it was simply > > uscan - it's using the GitHub tags rather than looking at PyPI, and the > > tag was never removed, so it's hard to see how it could have known any > > better. > > > > This does leave the question of how to hide that version from uscan in > > the future, since uscan doesn't make it easy to ignore specific upstream > > versions and I'd prefer to avoid using opaque regex constructions to do > > it. My best idea is to use uversionmangle to turn 2.1.0 into something > > like 2.0.8~pre1, but is there a better idiom? > > Ah I assumed the sources were being taken from pypi, if they are taken > from GitHub, then that explains yes. Perhaps using > https://pypi.org/project/catalogue/#files as the URL for uscan (if uscan > is happy with that one), would solve that problem? (And if it does, > then perhaps python packages should be progressively transitioned to > use pypi URLs to avoid this kind of problem?)
Some do, but it can't be done systematically: if we get the orig.tar from PyPI then it's the "sdist", which is built from the upstream repository, but Python's build tooling unfortunately means it's a bit easier than ideal for the sdist to be accidentally lacking some files, such as documentation or tests. Examples from a quick look in my browser history: https://github.com/RKrahl/pytest-dependency/pull/79 https://github.com/pgjones/quart-trio/pull/19 https://github.com/jendrikseipp/vulture/pull/368 > But I'm thinking that, perhaps the best option is to ask upstream > directly, whether they are going to release a 2.1.x release soon, or > if they could do that now, and/or whether they could perhaps > remove/rename the git tag perhaps (with the implied issues with messing > with history and git tags being sticky on cloned repos)? As I assume > other downstreams might be in the same/similar situation? Indeed. I've filed https://github.com/explosion/catalogue/issues/74 asking if they're willing to help out here. -- Colin Watson (he/him) [cjwat...@debian.org]