Re: on the lack of a `python-` prefix for source packages
On Mon, Dec 12, 2022 at 04:36:53AM +, Scott Kitterman wrote: > 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. I agree with Scott's reasoning here. Given that we prefix the binary packages with python3-, I strongly prefer to keep the source package name the same as upstream. I feel that way even for python modules and would vote against the requirement, but can understand and appreciate the other side of the argument. > 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). Agree here as well. Guidelines & reasonable defaults can be helpful for new contributors, but I really don't think we need a rule here -- whether or not it enshrines my (current) preference. > Scott K --Joe
Re: on the lack of a `python-` prefix for source packages
Am 12.12.2022 um 02:24 schrieb Sandro Tosi: 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 -> `python-` existing packages at a later date. What are other team members' opinions on this? I agree. The only exception should be a package with an executable that just happens to be implemented in Python. That is likely self-evident, but when packaging such a new package then one is likely also packaging a handful of its dependencies. Then all the dependencies likely got that python- prefix and then one may be tempted to also give it to the package featuring the executable. Best, Steffen
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
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 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
