Path: csiph.com!1.us.feeder.erje.net!3.us.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!weretis.net!feeder8.news.weretis.net!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod From: Scott Kitterman Newsgroups: linux.debian.maint.python Subject: Re: on the lack of a `python-` prefix for source packages Date: Mon, 12 Dec 2022 05:40:01 +0100 Message-ID: References: X-Mailbox-Line: From debian-python-request@lists.debian.org Mon Dec 12 04:37:48 2022 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:hard: -5.5 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailing-List: archive/latest/20583 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/0ADF6940-BFFA-4F44-947E-96529FE8084E@kitterman.com Approved: robomod@news.nic.it Lines: 55 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Mon, 12 Dec 2022 04:36:53 +0000 X-Original-Message-ID: <0ADF6940-BFFA-4F44-947E-96529FE8084E@kitterman.com> X-Original-References: <7B430D0B-5BEF-46E2-B1B1-75BC043B20A0@kitterman.com> <9755f395-9e26-2a43-c9bc-e3c426520632@debian.org> Xref: csiph.com linux.debian.maint.python:14717 On December 12, 2022 2:43:48 AM UTC, Sandro Tosi wrot= e: >> >> My proposal as stated at the top is to start from now on to prepend >> >> `python` to all NEW source packages in DPT, with the option to renam= e >> >> existing packages at a later date=2E >> >> >> >> What are other team members' opinions on this? >> > >> > For packages that on contain a python module/extension, I think it's = not horrible, but I don't see why it's better to diverge from upstream nami= ng=2E >> >> I tend to agree with Sandro on for this use case=2E > >True, i was mostly referring to modules, as that's the most numerous >type of packages we have > >> > For packages that contain or are primarily applications, I don't thin= k it's a good idea=2E >> >> Ditto on that one, I don't feel having "python-supysonic" would be a >> good naming scheme=2E=2E=2E > >please note that would be just for source packages, the user-facing >ones can still be `supysonic` as that's what you expect to install > >On Sun, Dec 11, 2022 at 8:53 PM Scott Kitterman = wrote: >> What problem are you trying to solve? > >no problem specifically, i just feel that having a consistent scheme >would benefit Debian and then team=2E If it's a case where multiple languages would likely have a package with s= imilar naming, I can see it's a good thing to be clear=2E When we already = don't use the same name as upstream in the binary (what upstream has python= 3- in the package name?), I think there's value in using the exact upstream= name for the source package=2E As an example, I maintain dkimpy (also the upstream name) which has the py= thon3-dkim binary package=2E If this were a new package that would follow = your proposed rule, what would the source package be named? If it's python= -dkim, that would follow your proposal, but a new user that knew the upstre= am name would find nothing if they searched for it=2E Python-dkimpy would = solve that, but seems redundant=2E I don't see how having an additional rule is helpful=2E I think every rul= e we add makes it more complicated for new contributors, so we should be ca= reful to avoid adding new ones without good reason (and it wouldn't hurt to= revisit old ones and ditch things that have outlived their usefulness)=2E Scott K