Path: csiph.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!bofh.it!news.nic.it!robomod From: Jeremy Stanley Newsgroups: linux.debian.maint.python Subject: Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs Date: Fri, 25 Jun 2021 23:20:02 +0200 Message-ID: References: X-Original-To: debian-python@lists.debian.org X-Mailbox-Line: From debian-python-request@lists.debian.org Fri Jun 25 21:17:39 2021 Old-Return-Path: X-Amavis-Spam-Status: No, score=-10.334 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, LDO_WHITELIST=-5, PGPSIGNATURE=-5, SARE_BOUNDARY_LC=1.666] autolearn=ham autolearn_force=no X-Policyd-Weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 CL_IP_EQ_FROM_MX=-3.1; rate: -4.6 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xbmktisllbhfwrlv" Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) X-Sa-Exim-Connect-IP: 2001:4802:7801:102:be76:4eff:fe20:63e0 X-Sa-Exim-Rcpt-To: debian-python@lists.debian.org X-Sa-Exim-Mail-From: fungi@yuggoth.org X-Sa-Exim-Scanned: No (on azathoth.yuggoth.org); SAEximRunCond expanded to false X-Mailing-List: archive/latest/19227 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/20210625211721.eluslf3hee5eug7r@yuggoth.org Approved: robomod@news.nic.it Lines: 56 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Fri, 25 Jun 2021 21:17:22 +0000 X-Original-Message-ID: <20210625211721.eluslf3hee5eug7r@yuggoth.org> X-Original-References: <877dihvfp9.fsf@DigitalMercury.dynalias.net> Xref: csiph.com linux.debian.maint.python:13437 --xbmktisllbhfwrlv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2021-06-25 16:42:42 -0400 (-0400), Nicholas D Steeves wrote: > I feel like there is probably consensus against the use of PyPi-provided > upstream source tarballs in preference for what will usually be a GitHub > release tarball, so I made an MR to this effect (moderate recommendation > rather than a "must" directive): >=20 > https://salsa.debian.org/python-team/tools/python-modules/-/merge_reque= sts/16 >=20 > Comments, corrections, requests for additional information, and > objections welcome :-) I'm also curious if there isn't consensus by > this point and if it requires further discussion I work on a vast ecosystem of Python-based projects which consider the sdist tarballs they upload to PyPI to be their official release tarballs, because they encode information otherwise only available in revision control metadata (version information, change history, copyright holders). The proposal is somewhat akin to saying that a tarball created via `make dist` is unsuitable for packaging. "GitHub tarballs" (aside from striking me as a blatant endorsement of a wholly non-free software platform) lack this metadata, being only a copy of the file contents from source control while missing other relevant context Git would normally provide. --=20 Jeremy Stanley --xbmktisllbhfwrlv Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmDWR9tfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCk4RhAAnWem4Mu200vr/io+xQhssXOAsRT+Gg9OIbnkAr4MnwCdT+XjWK7dDdrl mfht9BHoxMQUDkYmvH9kkQozNRJtvhEL8gE8UsLgBMZ8cBuSmnyEbnPv89cYJeRR B/29sarUYIoKD6NDx/tIRQmHWOUDq+r7eVD33RWfvLwiw7qpGmAGWZI5Imv3/YXP DLFQtuDPkF/QGuUNmVr6JBVrOiYtXZVlbP0FV5ouFGgiV2T/6XvWWD+eC7cdOpTQ aqpBnArF/OqvWVQkEI8ls4afj06Zlet83SOeP8K7qOYNOdIkcB57HRZf+euRb/D2 A0nVc//o6hCnD6AZ9hNPjZsz08nvCgV4F3sr3GkNAcW9Q8VV3vYkDRKwOoJwQS8p TfxYCtUh2d19Ex07cDDCf2cH0ViApNZduNqJtkxCrh8+O1eTgTz3yH5/4VlUfalX 5104+pZeYwrFylKcdwZQKZOjO46jsWeBuDyNP5TRLtkQC1LsRmW3kdbIi0k+IHY8 iOXHUv++Tkmn7dySKtRBC9bDVOks8rNrYW6eKiNBc82RC5t5d8u3jaUU/0/CduiE +gKeXam9Q6GJyDF4JgvZeRSZKGyHwHnWGjyp4LODN7Vbs9BXdJAHc00VzPaeS0G2 z1FgW4mCTW/YHjUzSoegIJDm0c1m+OsqlYF+XVXaiQ18mDukXlM= =DOn1 -----END PGP SIGNATURE----- --xbmktisllbhfwrlv--