Julian Gilbey <jul...@d-and-j.net> writes: > On Sun, Dec 22, 2024 at 06:23:24PM +0100, Simon Josefsson wrote: >> So far I've only noticed that some self-tests and auxilliary files are >> missing from the PyPI tarballs, and I don't consider that to be >> important enough to deviate from using the pypi.debian.net sources yet. > > Hi Simon, > > There is no Debian Python policy to use PyPI versus GitHub versions as > far as I am aware. However, the PyPI versions of packages frequently > do not include the test suites, as many developers regard those as > part of the development environment, not the release environment (and > having test suites included in all packages could cause significant > bloat). You are, of course, welcome to ask them to reconsider for > this package, but you may not have any success, and I wouldn't rely on > them agreeing to your request. > > Whatever the outcome of your negotiations, the Debian Python team is > very keen on having autopkgtests for as many packages as possible: > doing so catches all sorts of bugs and can prevent your package from > mysteriously breaking. So given that upstream have written a test > suite that you have easy access to (via GitHub), unless you have a > very strong reason *not* to include it in the Debian sources, you > really ought to do so. "It isn't included in the PyPI source tarball" > is not a strong reason. So it seems that you have a few choices: > > (1) Use the GitHub sources in place of the PyPI sources. > > (2) Use the GitHub sources, patched in those few places where the PyPI > version differs to match the PyPI version. (This can be done via > debian/patches.) > > (3) Use the PyPI sources and include the test suite from GitHub; this > could be done via the dpkg-source components mechanism, for example. > It would complicate the packaging a bit, and make upgrading harder > work, but it would certainly be feasible. > > (4) Decide on principle that you're going to stick with the PyPI > version come what may, and as upstream haven't included a test suite > in that version, the Debian package won't either. > > > I am sure I'm not alone on the Debian Python Team in strongly > discouraging you from following option (4). My personal preference > would be (1) or (2), depending on how significantly different the > GitHub and PyPI versions are. (And this does also assume that the > developers have tagged their Git repository with appropriate tags.)
Thank you! I'm happy to adopt 1) but I didn't want to do that without some +1 on doing so since https://wiki.debian.org/Python/LibraryStyleGuide?action=show&redirect=Python%2FPackaging#debian.2Fwatch says 'Thus, it is highly recommended that you update your existing packages to the new debian/watch format described here' and 'Since probably for most of our packages, the original tarball comes from the Python Package Index (a.k.a. PyPI or the Cheeseshop)' which give me the impression that using PyPI tarballs is generally preferred, so it is hard for me as newbie to understand the preferences. I do agree that self-tests are important, and I was surprised maintainers don't include them in the PyPI tarballs. Maybe it is not worth our time to open bug reports about changing the PyPI tarballs, and switching to the GitHub tarballs is fine. Another question is about which version to package -- latest GitHub tag or PyPI version? Have a look at this project: https://pypi.org/project/sigstore-protobuf-specs/#history I suppose I may run into whatever bug that prompted this yanking too... /Simon
signature.asc
Description: PGP signature
