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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On December 12, 2022 1:24:35 AM UTC, Sandro Tosi <morph@debian.org> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 <debian@kitterman.com> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Q0mRdVntLDI04Y0YQ632l4lc
Content-Type: multipart/mixed; boundary="------------QA0oTEtqCeK8xGHl5kX6xE0x"

--------------QA0oTEtqCeK8xGHl5kX6xE0x
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

T24gMjAyMi0xMi0xMSAyMCBoIDUzLCBTY290dCBLaXR0ZXJtYW4gd3JvdGU6DQo+IA0KPiAN Cj4gT24gRGVjZW1iZXIgMTIsIDIwMjIgMToyNDozNSBBTSBVVEMsIFNhbmRybyBUb3NpIDxt b3JwaEBkZWJpYW4ub3JnPiB3cm90ZToNCj4+IFByb3Bvc2FsOiB0aGUgRFBUIHdpbGwgc3Rh cnQgYWRkaW5nIGEgYHB5dGhvbi1gIHByZWZpeCB0byBORVcgc291cmNlDQo+PiBwYWNrYWdl cyBuYW1lcywgdW5sZXNzIHRoZSB1cHN0cmVhbSBwcm9qZWN0IGFscmVhZHkgY29udGFpbnMg aXQNCj4+DQo+PiBBRkFJQ1QgYWxsIG90aGVyIG1ham9yIGxhbmd1YWdlcyBlY29zeXN0ZW1z IHBhY2thZ2luZyB0ZWFtcyB1c2UgYQ0KPj4gKHNlbWk/KW1hbmRhdG9yeSB0YWcgdG8gaWRl bnRpZnkgdGhlaXIgc291cmNlIHBhY2thZ2VzIChyZXN1bHRzIGJlbG93DQo+PmZyb20gYSB2 ZXJ5IHF1aWNrIGxvb2sgYXQgU291cmNlcywgdG9wIHJlc3VsdHMgb25seSk6DQo+Pg0KPj4g cHJlZml4OiBnb2xhbmcsIHJ1c3QsIHIsIG5vZGUsIHJ1YnksIGhhc2tlbGwsIHBocCwgb2Nh bWwsIHB5dGhvbiAob24gYQ0KPj4gdm9sdW50YXJ5IGJhc2lzKSwgYW5kIG90aGVycw0KPj4g cHJlZml4K3N1ZmZpeDogcGVybA0KPj4NCj4+IEF0IHRoZSBiZWdpbm5pbmcsIEkgcmVtZW1i ZXIgYmVpbmcgaW4gZmF2b3Igb2YgdGhlIGN1cnJlbnQgc3RhdHVzIHF1bw0KPj4gaW4gRFBU LCB3aGVyZSBlYWNoIG1haW50YWluZXIgY2FuIGNob29zZSB0byBhZGQgYHB5dGhvbi1gIGlm IHRoZXkgZmVlbA0KPj4gbGlrZSBpdCwgb3IganVzdCB1c2UgdGhlIHVwc3RyZWFtIG5hbWUu DQo+Pg0KPj4gVGhydSB0aGUgeWVhcnMsIGkndmUgZ3Jvd24gbW9yZSB1bmNvbWZvcnRhYmxl IHdpdGggdGhpcyBzaXR1YXRpb24gYW5kDQo+PiBpIHRoaW5rIHRoZSBmYWN0IHdlIGRvbnQg bWFuZGF0ZSBhIGBweXRob25gIHByZWZpeCBpbiB0aGUgdGVhbSBzb3VyY2UNCj4+IHBhY2th Z2VzIG5hbWVzIChhbmQgdGh1cyBndWlkaW5nIHRoZSByZXN0IG9mIHRoZSBweXRob24gcGFj a2FnZXJzDQo+PiB3aXRoaW4gRGViaWFuIHRvd2FyZHMgYSBjb21tb24gc3R5bGUpIGlzIGRl dHJpbWVudGFsIHRvIERlYmlhbiBhcyBhDQo+PiB3aG9sZSwgYW5kIHdlIHNob3VsZCBjaGFu Z2UgaXQuDQo+Pg0KPj4gTXkgcHJvcG9zYWwgYXMgc3RhdGVkIGF0IHRoZSB0b3AgaXMgdG8g c3RhcnQgZnJvbSBub3cgb24gdG8gcHJlcGVuZA0KPj4gYHB5dGhvbmAgdG8gYWxsIE5FVyBz b3VyY2UgcGFja2FnZXMgaW4gRFBULCB3aXRoIHRoZSBvcHRpb24gdG8gcmVuYW1lDQo+PiBl eGlzdGluZyBwYWNrYWdlcyBhdCBhIGxhdGVyIGRhdGUuDQo+Pg0KPj4gV2hhdCBhcmUgb3Ro ZXIgdGVhbSBtZW1iZXJzJyBvcGluaW9ucyBvbiB0aGlzPw0KPiANCj4gRm9yIHBhY2thZ2Vz IHRoYXQgb24gY29udGFpbiBhIHB5dGhvbiBtb2R1bGUvZXh0ZW5zaW9uLCBJIHRoaW5rIGl0 J3Mgbm90IGhvcnJpYmxlLCBidXQgSSBkb24ndCBzZWUgd2h5IGl0J3MgYmV0dGVyIHRvIGRp dmVyZ2UgZnJvbSB1cHN0cmVhbSBuYW1pbmcuDQoNCkkgdGVuZCB0byBhZ3JlZSB3aXRoIFNh bmRybyBvbiBmb3IgdGhpcyB1c2UgY2FzZS4NCg0KPiBGb3IgcGFja2FnZXMgdGhhdCBjb250 YWluIG9yIGFyZSBwcmltYXJpbHkgYXBwbGljYXRpb25zLCBJIGRvbid0IHRoaW5rIGl0J3Mg YSBnb29kIGlkZWEuDQoNCkRpdHRvIG9uIHRoYXQgb25lLCBJIGRvbid0IGZlZWwgaGF2aW5n ICJweXRob24tc3VweXNvbmljIiB3b3VsZCBiZSBhIA0KZ29vZCBuYW1pbmcgc2NoZW1lLi4u DQoNCi0tIA0KICAg4qKA4qO04qC+4qC74qK24qOm4qCADQogICDio77ioIHioqDioJLioIDi o7/ioYEgIExvdWlzLVBoaWxpcHBlIFbDqXJvbm5lYXUNCiAgIOKiv+KhhOKgmOKgt+KgmuKg iyAgIHBvbGxvQGRlYmlhbi5vcmcgLyB2ZXJvbm5lYXUub3JnDQogICDioIjioLPio4QNCg0K

--------------QA0oTEtqCeK8xGHl5kX6xE0x
Content-Type: application/pgp-keys; name="OpenPGP_0xE1E5457C8BAD4113.asc" Content-Disposition: attachment; filename="OpenPGP_0xE1E5457C8BAD4113.asc" Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEYEPdjBYJKwYBBAHaRw8BAQdA5yh8SOHhcvKeX/A4rv0/JTCL8Kgnnwy4/okK h1Htbs3NOExvdWlzLVBoaWxpcHBlIFbDqXJvbm5lYXUgPGxvdWlzLXBoaWxpcHBl QHZlcm9ubmVhdS5vcmc+wpkEExYKAEECGwMFCQHhM4AFCwkIBwMFFQoJCAsFFgID AQACHgECF4AWIQT2TWHTIfPLSJFWdT3h5UV8i61BEwUCYEPeHgIZAQAKCRDh5UV8 i61BE0xKAP4oRsMaA2T/Zjge126dwHbnxBsjI/Q3ky8QkGlOffUKJAEA9dWm0hE4 0URSXM8Ndtf+GeHxvNeryVMCtVDUfjHMBA/CmQQTFgoAQQIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAIZARYhBPZNYdMh88tIkVZ1PeHlRXyLrUETBQJiEWgLBQkD rr3/AAoJEOHlRXyLrUETOK0BAM9I6BMMiqhsORsRcDVcM4VTm8G67YHapBW5zdl/ llfxAPwLAsi32TCPWjuwD3UdKig+6syvKFsiIfjiNBweNIQED80sTG91aXMtUGhp bGlwcGUgVsOpcm9ubmVhdSA8cG9sbG9AZGViaWFuLm9yZz7ClgQTFgoAPhYhBPZN YdMh88tIkVZ1PeHlRXyLrUETBQJgQ93rAhsDBQkB4TOABQsJCAcDBRUKCQgLBRYC AwEAAh4BAheAAAoJEOHlRXyLrUETeLMBAJAAznKkFo3Cm0pAW6klHv6jnDeMLS/6 9tAbJQRDNEAhAQDGQTrcAJZAcAFKoYeh2UlRokm1xG3Lc+FDpZGOKJBaBcKWBBMW CgA+AhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAFiEE9k1h0yHzy0iRVnU94eVF fIutQRMFAmIRaAsFCQOuvf8ACgkQ4eVFfIutQRMItwD+Oce5l0QBRJsax1C5MXe3 7Jk5cIMV2eOH0i4hd6c2wqYA/31Wn0qt5bv7i1y+2JsCeKtv0MIsYQ3LU1XG8k9h pb8BzjMEYEPg0RYJKwYBBAHaRw8BAQdASbekNA3xJnxUhMenK8ttfm8OTepniXHJ EN0Sm1/zmifCwDUEGBYKACYWIQT2TWHTIfPLSJFWdT3h5UV8i61BEwUCYEPg0QIb AgUJAeEzgACBCRDh5UV8i61BE3YgBBkWCgAdFiEEyqdABweoFrAgL8PN9CV6ULIc +oUFAmBD4NEACgkQ9CV6ULIc+oWswwEAoRTzlukc6Ss4PaChogmudTzMdezF1FQz T5HH0C4EVawA/1JfaysK+seL/zdEQKUHD3cMdg8NvMtOXfcMg4EiFRYE1SQBAPKi UCqSMLql7QtWiB/xmDFUYltNa3+NLjRYRsNKfe9JAP9ZEaXY6oO+3owwpxbNphBp hSkH+9lEag0Dd3BEowOKDMLANQQYFgoAJgIbAhYhBPZNYdMh88tIkVZ1PeHlRXyL rUETBQJiEnvDBQkDr85yAIF2IAQZFgoAHRYhBMqnQAcHqBawIC/DzfQlelCyHPqF BQJgQ+DRAAoJEPQlelCyHPqFrMMBAKEU85bpHOkrOD2goaIJrnU8zHXsxdRUM0+R x9AuBFWsAP9SX2srCvrHi/83REClBw93DHYPDbzLTl33DIOBIhUWBAkQ4eVFfIut QRPY6AEAn9YvrTzliAvnyPef3kXXCvyH973dPn/539suXireBnsA/iqtwiOe4758 +28fgsXaVUpyFcEhirsu0/IhzSnpVXUNzjgEYEPg5RIKKwYBBAGXVQEFAQEHQIES 2w30v+hi13deaiPcx7KPVMCUIA25nu6by9Wfa5BuAwEIB8J+BBgWCgAmFiEE9k1h 0yHzy0iRVnU94eVFfIutQRMFAmBD4OUCGwwFCQHhM4AACgkQ4eVFfIutQRMNhgD9 HkVqB+Vy+F9EAzjHilHnSPft2xfLdhTrqzh6O0jEhqsA/2dd/AMSsZNAH8FYQKq3 Th+Hikj+jXXs+P9HYlULp1UHwn4EGBYKACYCGwwWIQT2TWHTIfPLSJFWdT3h5UV8 i61BEwUCYhJ72AUJA6/OcwAKCRDh5UV8i61BE2CVAP9+JHidrPFWE7WwNskxdVY1 YzHxGihO20Zt65AagSMVgAD9FlBCTPfQKpvC5jBax89pLAg07QsLq1wJ5U5v1zV5 JQTOMwRiEWorFgkrBgEEAdpHDwEBB0BkhUACsGCOaaPRY4H2lJiegjp8hFrduGkl t4qxMygJ88J4BCgWCgAgFiEE9k1h0yHzy0iRVnU94eVFfIutQRMFAmLoLeYCHQMA CgkQ4eVFfIutQROVZAD9E2NDG9xBqa7gZjYprQkY4EzUgUkZY5g5l046jI0WvN8B APK0Ab4Sjx7ekPJDDa4gB/Mr1htCyoZrPysKB7tkuCQDwsA1BBgWCgAmFiEE9k1h 0yHzy0iRVnU94eVFfIutQRMFAmIRaisCGwIFCQHhM4AAgQkQ4eVFfIutQRN2IAQZ FgoAHRYhBJBd8+ORq1094UcSk2a2zWq+wNuWBQJiEWorAAoJEGa2zWq+wNuWOv8B AKfeLq2soJeiHDAdoV0spQxoVJDme2FzgmBCxr0KxRfQAP9zaHwI9+NjirmC8Gov IGveZ7wxXJ/v8jYFnZadVhIRBqk+AQDXKlTmPsWLD6SnMvW+kF1SbHUq6aPqALXb nEai/hTTrAD+Pt7NZO1KqJQiIJ+miP1LIlPqiZKMPt8uNdw8KKqHVwbOOARiEXES EgorBgEEAZdVAQUBAQdAZSMCxsNHkDiI2tnp9FX1Xl+39/Knre9jd7exta0LGAED AQgHwngEKBYKACAWIQT2TWHTIfPLSJFWdT3h5UV8i61BEwUCYuguFwIdAwAKCRDh 5UV8i61BE3D3APsH9gDArOrY6/d2/Lefpymj+yR5DHDEWpEvQ+GTnnA9ewEA6LgH Gx3DRN/KfkW1eoXxlnaFeQPXqggLOFj8kzYkDgDCfQQYFgoAJhYhBPZNYdMh88tI kVZ1PeHlRXyLrUETBQJiEXESAhsMBQkB4TOAAAoJEOHlRXyLrUETinYA93idFyhp u054EVRbFz/ybVAlpGqkdt69+LYt3Cr0RIkBANARMMYd47lV/1/C1fWsemRuZDCd +BzH/o7byibkUa4O
=hixQ
-----END PGP PUBLIC KEY BLOCK-----

--------------QA0oTEtqCeK8xGHl5kX6xE0x--

--------------Q0mRdVntLDI04Y0YQ632l4lc--

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQTKp0AHB6gWsCAvw830JXpQshz6hQUCY5aOoQAKCRD0JXpQshz6 hRDWAQDiwsLFiu+dTUfXxXw8MnTtQa32qVoFajlF+TUC+Wwo3QD/aP/5SNwlPtJp VJmBJrJXmmDWYx0tEhPvWi2abXDdAAw=
=XQgA
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On December 12, 2022 2:43:48 AM UTC, Sandro Tosi <morph@debian.org> 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 <debian@kitterman.com> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Dec 12, 2022 at 04:36:53AM +0000, Scott Kitterman wrote:

On December 12, 2022 2:43:48 AM UTC, Sandro Tosi <morph@debian.org> 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 <debian@kitterman.com> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)