Path: csiph.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!bofh.it!news.nic.it!robomod From: Scott Talbert Newsgroups: linux.debian.maint.python Subject: Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs Date: Fri, 25 Jun 2021 23:40:01 +0200 Message-ID: References: X-Mailbox-Line: From debian-python-request@lists.debian.org Fri Jun 25 21:35:24 2021 Old-Return-Path: X-Amavis-Spam-Status: No, score=-7.2 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, LDO_WHITELIST=-5] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate: -4.6 X-Greylist: delayed 536 seconds by postgrey-1.36 at bendel; Fri, 25 Jun 2021 21:35:12 UTC X-X-Sender: talbert@bear.techie.net User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Mailing-List: archive/latest/19228 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/alpine.DEB.2.22.394.2106251722020.69542@bear.techie.net Approved: robomod@news.nic.it Lines: 30 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Cc: debian-python@lists.debian.org X-Original-Date: Fri, 25 Jun 2021 17:25:45 -0400 (EDT) X-Original-Message-ID: X-Original-References: <877dihvfp9.fsf@DigitalMercury.dynalias.net> <20210625211721.eluslf3hee5eug7r@yuggoth.org> Xref: csiph.com linux.debian.maint.python:13438 On Fri, 25 Jun 2021, Jeremy Stanley 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): >> >> https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/16 >> >> 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. I tend to agree about PyPI being the official releases for a lot of projects. "GitHub tarballs" also tend to include other undesirable stuff for distribution like upstream CI/CD configuration files, etc. Scott