PEP517

> And none of the authors of these pieces of software relying on this functionality working ever seem to be aware of the problem.

> i.e. All of it is solvable, it's just that it's a lot of work across a lot of different projects, and I don't think many of them are aware of the need to even do it.

My experience of discussion in Python packaging circles has been: people are very aware that Python code gets used and distributed in a wide variety of ways beyond the standard packaging system. But the people who try to "solve packaging" have very little idea of how to track down major projects that work this way. It often seems like the best they can do is to trawl through PyPI looking for sdists that will break in the future and send emails to whatever maintainer email addresses are listed in the metadata. If they don't publish an sdist then there's no clear way to figure out what their needs are to service them better.

A bit of speculation as well as *personal* investigation from Paul Moore (of the pip team) led to his submission of PEP 722, subsequently rejected in favour of PEP 723 by Ofek Lev (author of Hatch). That makes life easier for people who write single-file scripts with dependencies. But there are still huge unanswered questions about several other kinds of projects, e.g. large monorepos.

I had a bunch of post IDs saved on the Python Discourse forums about this general topic, but I lost those when I got kicked out (https://zahlman.github.io/posts/2024/07/31/an-open-letter... ; you may also remember me from https://lwn.net/Articles/988894/) and my local bookmark collection is quite large and hard to organize.

If you personally know people (or projects) that use deprecated workflows around setup.py, I'd heavily encourage you to warn them - and link to https://blog.ganssle.io/articles/2021/10/setup-py-depreca... . If you know projects that use only Python but publish only a "legacy" sdist instead of wheels, https://pradyunsg.me/blog/2022/12/31/wheels-are-faster-pu... is a solid reference.

If they otherwise make inappropriate use of setup.py (e.g. to convey metadata that could be in a pyproject.toml), probably the best way to warn them is to point out what happened to Requests with Setuptools version 78 (and 72): twice in less than a year, one of the most popular projects out there, written in pure Python, had its packaging break twice in easily avoidable and completely unnecessary ways. Packaging is part of maintenance, too.

But for those who don't publish to PyPI and whose projects aren't a dependencies for anything else, there might not actually *be* a need to do anything - except to stop upgrading local installations of Setuptools.