Re: on the lack of a `python-` prefix for source packages
On 2022-12-11 20 h 53, Scott Kitterman wrote: On December 12, 2022 1:24:35 AM UTC, Sandro Tosi wrote: Proposal: the DPT will start adding a `python-` prefix to NEW source packages names, unless the upstream project already contains it AFAICT all other major languages ecosystems packaging teams use a (semi?)mandatory tag to identify their source packages (results below from a very quick look at Sources, top results only): prefix: golang, rust, r, node, ruby, haskell, php, ocaml, python (on a voluntary basis), and others prefix+suffix: perl At the beginning, I remember being in favor of the current status quo in DPT, where each maintainer can choose to add `python-` if they feel like it, or just use the upstream name. Thru the years, i've grown more uncomfortable with this situation and i think the fact we dont mandate a `python` prefix in the team source packages names (and thus guiding the rest of the python packagers within Debian towards a common style) is detrimental to Debian as a whole, and we should change it. 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 rename existing packages at a later date. 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 naming. I tend to agree with Sandro on for this use case. For packages that contain or are primarily applications, I don't think it's a good idea. Ditto on that one, I don't feel having "python-supysonic" would be a good naming scheme... -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_0xE1E5457C8BAD4113.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: on the lack of a `python-` prefix for source packages
On December 12, 2022 1:24:35 AM UTC, Sandro Tosi wrote: >Proposal: the DPT will start adding a `python-` prefix to NEW source >packages names, unless the upstream project already contains it > >AFAICT all other major languages ecosystems packaging teams use a >(semi?)mandatory tag to identify their source packages (results below >from a very quick look at Sources, top results only): > >prefix: golang, rust, r, node, ruby, haskell, php, ocaml, python (on a >voluntary basis), and others >prefix+suffix: perl > >At the beginning, I remember being in favor of the current status quo >in DPT, where each maintainer can choose to add `python-` if they feel >like it, or just use the upstream name. > >Thru the years, i've grown more uncomfortable with this situation and >i think the fact we dont mandate a `python` prefix in the team source >packages names (and thus guiding the rest of the python packagers >within Debian towards a common style) is detrimental to Debian as a >whole, and we should change it. > >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 rename >existing packages at a later date. > >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 naming. For packages that contain or are primarily applications, I don't think it's a good idea. What problem are you trying to solve? Scott K
on the lack of a `python-` prefix for source packages
Proposal: the DPT will start adding a `python-` prefix to NEW source packages names, unless the upstream project already contains it AFAICT all other major languages ecosystems packaging teams use a (semi?)mandatory tag to identify their source packages (results below from a very quick look at Sources, top results only): prefix: golang, rust, r, node, ruby, haskell, php, ocaml, python (on a voluntary basis), and others prefix+suffix: perl At the beginning, I remember being in favor of the current status quo in DPT, where each maintainer can choose to add `python-` if they feel like it, or just use the upstream name. Thru the years, i've grown more uncomfortable with this situation and i think the fact we dont mandate a `python` prefix in the team source packages names (and thus guiding the rest of the python packagers within Debian towards a common style) is detrimental to Debian as a whole, and we should change it. 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 rename existing packages at a later date. What are other team members' opinions on this? Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: on the lack of a `python-` prefix for source packages
> >> 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 rename > >> existing packages at a later date. > >> > >> 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 naming. > > I tend to agree with Sandro on for this use case. 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 think it's > > a good idea. > > Ditto on that one, I don't feel having "python-supysonic" would be a > good naming scheme... 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. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: on the lack of a `python-` prefix for source packages
On December 12, 2022 2:43:48 AM UTC, Sandro Tosi wrote: >> >> 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 rename >> >> existing packages at a later date. >> >> >> >> 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 naming. >> >> I tend to agree with Sandro on for this use case. > >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 think >> > it's a good idea. >> >> Ditto on that one, I don't feel having "python-supysonic" would be a >> good naming scheme... > >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. If it's a case where multiple languages would likely have a package with similar naming, I can see it's a good thing to be clear. When we already don't use the same name as upstream in the binary (what upstream has python3- in the package name?), I think there's value in using the exact upstream name for the source package. As an example, I maintain dkimpy (also the upstream name) which has the python3-dkim binary package. 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 upstream name would find nothing if they searched for it. Python-dkimpy would solve that, but seems redundant. I don't see how having an additional rule is helpful. I think every rule we add makes it more complicated for new contributors, so we should be careful 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). Scott K