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]

Reply via email to