Hi Adrian (2026.11.03_05:21:05_+0000)
On Tue, Oct 20, 2026 at 01:33:09PM +0000, Stefano Rivera wrote:
...
I note that the version in unstable doesn't include these files, and it
isn't immediately obvious to me where the regression is. Probably in
setuptools.
...

The regression is in dh-python.

You broke something that Piotr added intentionally 11 years ago,
and based on your comment that was unintentional.

This message is missing a lot of context. Here's how I understand this set of bugs unfolding:

1. Some upstreams don't think too much about what they install. I don't think pip has any protection for packages installing over each other, and this doesn't seem to have been an issue.

2. 11 years ago dh_python3 started to delete "test" and "tests" directories in dist-packages.
   
https://salsa.debian.org/python-team/tools/dh-python/-/commit/7536d5a9041131dab2156450ebb1cd618b87cf1a

3. This was later extended to delete ".*" directories too.

4. We prepared for the python 3.15 transition, and hit a few snags:
1. Packages building differently under Python 3.14 and 3.15. This only shows up when we have 2 supported Python versions and the trees can't be merged.

2. Packages buliting twice in the same directory started to install build artifacts from the first build in the second install. This is the likely setuptools regression I described above.

Setuptools used to have some heuristic defences against this. The "finder" system had a blocklist of words that wouldn't be found unless explicitly requested. For a few reasons (that I can't recall right now, and I really can't be bothered to go digging for) this has not worked reliably in Debian in the past, even though we have contributed words to them.

Building twice in a dirty tree is something that CI-centric upstreams don't do very much, but we do during Python transitions. So we're typically on the front line for these issues.

5. These issues and proposed solutions were discussed on MRs and #debian-python IRC. I think there was reasonable consensus for them, so I find your tone here rather inappropriate. I expect you wouldn't have seen those discussions, so I do understand it, but it's still not really in the spirit of collaboration.

6. To resolve 4.1, after expermenting with ways to merge them, we dedided to blow up rather than leave anything unmerged. This would make the issue clear to the maintainer who could decide on the right thing to do, rather than leaving a messy install tree that likely nobody would notice.

   
https://salsa.debian.org/python-team/tools/dh-python/-/commit/00a6dac429b9e7d6cff129c5645e0658cef1a286

5. To resolve 4.2 we decided to blow up if these issues were detected.

I also proposed an approach where we build wheels from isolated builds of sdists:
   https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/100

But that's likely to have more unforseen outcames (that are harder to detect) than this approach. We still should do this, but with more testing and diff-review. Not something to figure out during the start of a transition.

I replaced the code that deleted test and tests directories with something that threw an error if any of a range of module names was detected. This is the change you are referencing, and yes it causes a regression for packages that used to install a test/tests module.

   
https://salsa.debian.org/python-team/tools/dh-python/-/commit/7ce9edd0d3568010e391e299a10057e37e1a81f3

For the wide range of build directory names that I wanted to detecet, it wouldn't make sense to just delete the directories silently. Throwing errors is a much better way to get the individual review that these cases should have. So, that's what I did.


6. ".*" directories started to clash with both 3.14 and 3.15 supported, because the cleanup step from 2 was applied before the merge. We solved this by sammarily deleting ".*" directories earlier. I'm not sure why this wasn't as much of an issue in previous Python transitions.

   
https://salsa.debian.org/python-team/tools/dh-python/-/commit/5b9b7185b9f76b4bf076ee6583c4d6bc95cf87cd

There was a window where we simply didn't delete these, but blew up (4.1 above), but deleting them was clearly the best option, so we re-instated this.

   
https://salsa.debian.org/python-team/tools/dh-python/-/commit/61aba7744f956c4ad0cdc8bcbea259bb93671b3b

Stefano

--
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Reply via email to