Hi! Given recent ITP discussions [0] about lack of namespacing on python module source package names, I think it would be really good to fix this at the source, by mandating it in the python-policy. Attached is a proposal wording. [0] #748383: ITP: bash8; #745347: ITP: releases; #790399: ITP: structlog Thanks, Guillem
The right place to discuss Debian Python Policy changes is debian-python@lists.debian.org mailing list. (and I'm strongly against this change, BTW)
Dear submitter, as the package python-defaults has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see https://bugs.debian.org/1027107 The version of this package that was in Debian prior to this removal can still be found using https://snapshot.debian.org/. Please note that the changes have been done on the master archive and will not propagate to any mirrors until the next dinstall run at the earliest. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org. Debian distribution maintenance software pp. Scott Kitterman (the ftpmaster behind the curtain)
[ Sorry, resending, as the bug was archived so it ignored all the control commands. ] This got closed due to the python-defaults package being removed from sid, reopening and reassigning where python-policy seems to be located now. Thanks, Guillem
Do we really have to have this argument again? Let's not. Please wontfix and let's move on. Personally, I maintain 25 packages in the team that would need renaming. I'm not sure how many total there are, but they'd all have to go through New again. It'd be much simpler just to drop DPT or myself from uploaders and ignore this, so that's probably the path I would take. Regardless, I don't think this is an appropriate use of FTP Team time/energy. Also, as I've said before on this topic, every packaging rule is a barrier to entry for new contributors. We really shouldn't add things that aren't needed. Scott K
Hi Scott (2023.01.29_01:34:54_+0000) The Debian Python Policy is independent of DPT. So, if adopted, that wouldn't help much... :) +1. I could live with this being a recommendation for new source packages, but it don't really see the value in renaming existing source packages. SR
I definitely think any changes ought to be new packages only. I could live with "upstream name or python-$modulename" for the source package. Generally when I've deviated from python-$modulename it's been to align to the upstream naming convention. Scott K
Hi! [ I never received a reply so was not aware some conversation had been going on. :) I've rearranged the replies a bit. ] If Debian only contained python packages, that would make sense, because python modules upstream need to care about not stomping over each others names. But Debian contains source packages for multitude of projects and language ecosystems, where their own modules can and do share the same short and generic or conflicting module names with many other language ecosystems modules (say json modules). These also can conflict with command-line tools which use another common namespace, etc. Pretty much every other language specific team in Debian namespaces their _source_ and _binary_ packages to avoid stomping/grabbing on the global namespace. I don't really understand what makes python special here, that it cannot follow a similar pattern. :/ I was under the impression that these did still not require NEW trips, or had not associated that the dak support for overrides for sources implied that renames for these now (obviously) need to go through NEW, until Scott mentioned this on d-d (thanks!). Which while it makes sense that they'd also go through NEW, it now implies cleanups like this cannot be easily done w/o going through additional hoops. I do think though that this kind of thing is precisely what a NEW check should be doing (and used to imply too, long ago AFAIR), as the archive admins are responsible for both the contents (f.ex. license-wise), organization (overrides) and the *namespace* of the packages in the archive. I guess whether "upstream name or python-$modulename" would seem fine, depends on what "upstream name" is. I guess if the latter is something like "py<something>" or some widely known sub-ecosystem that is really very much python-specific, and there is no chance of that ever being present in other language ecosystems (which ahem), then I guess that could be fine, but it's hard to tell from just "upstream name", given what I've seen. :) The above, and restricting to only new source packages, still seems rather unsatisfactory to me, in terms of namespace handling, and management of such shared resource. But, assuming the "upstream name" part can be made less fuzzy, I'd take a policy that stops making the problem worse, and which applies only to new source packages, than none at all. I can try to propose new wording. See above for the reasoning. I can relate to that in the extreme, but to me the key is that managing namespaces is precisely one of the essential things a distribution does and needs to do, as part of its integration and cohesion work to make all those random and disparate parts that we are gluing together work in concert, and in a way that is easier to understand and handle at scale. Thanks, Guillem
src:dbus-python, src:tap.py and src:pygobject seem like some examples of
upstream names that are fine (not going to conflict with other ecosystems)
despite not fitting the /^python-/ pattern.
But, looking at some packages that I happen to have installed, I think
I agree with Guillem that names like src:alabaster and src:binaryornot
seem too generic to be ideal.
smcv
Hi Guillem (2024.10.18_13:31:26_+0000) It's worth drawing a distinction between libraries and apps here. I think it would be silly to namespace application source packages that are already installing a binary of that name. The fact that they are implemented in Python is hardly relevant. It's easier for everyone when the source and binary package names are the same, and match upstream's name. In general, namespacing libraries makes sense. Either with python- or whatever ecosystem they are part of. Stefano
Control: retitle -1 python-policy: Suggest conventional namespacing for Python modules' source packages Control: forwarded -1 https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/19 Control: tags -1 + patch Prompted by discussion with a new packager on debian-python (in which I wanted to refer the new packager to documentation, but then discovered that the documentation I wanted didn't exist), I've written some possible wording. Please see: https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/19 The guidance I've proposed is specific to source packages that mainly exist to install Python modules (the things other ecosystems might call "libraries"). Applications that happen to be written in Python, like meson and d-feet, do not need to follow it (and IMO they should not: the source package names meson and d-feet are more appropriate than python-meson or python-d-feet). smcv