Empathy?

Posted May 22, 2025 13:08 UTC (Thu) by lunaryorn (subscriber, #111088)
Parent article: Recent disruptive changes from Setuptools

I pity the setuptools maintainers.

They're keep dragging around a big pile of odorous excrements from two decades of failed approaches to Python packaging, but whenever they make even the slightest attempt at cleaning up this huge mess things break back and forth because there's always this one small, old, unmaintained package, with obscure packaging scripts none understands anymore, that for some obscure reason half the world seems to depend upon, and for which three decades of deprecation period wouldn't be enough.

When they achieve the occasional trace amount of success no one notices, no one appreciates, no one pays.

But when the fail at a mere two percent of existing packages the whole world comes down on them with indignation and outrage, often from people who'd not even in their dreams live up to the standards of maintenance they seem to expect from the volunteer setuptools maintainers.

They never stand any chance. The community doesn't help them, and they don't have any kind of tooling for quality assurance on a scale of 630k packages.

We wouldn't expect a well-paid carpenter to build a skyscraper with but a hammer, but we somehow seem to expect unpaid volunteers to build the seven wonders of Python packaging in their spare time.

Empathy?

Posted May 27, 2025 10:33 UTC (Tue) by LtWorf (subscriber, #124958) [Link] (3 responses)

Let's not forget that python had distutils as part of the standard library but dropped it.

The entire idea that pip and setuptools and venv exist outside of the standard library and aren't part of python is the mistake here.

Empathy?

Posted May 27, 2025 12:18 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

How do you reconcile being outside of the CPython repository "the mistake" as well as:

> Because being too static and unmoving is not a good characteristic in python.

Is the stdlib far harder to change than an external package? You also get the possibility of using newer {venv,pip,setuptools} with older Python releases (or older versions with newer Python in the case of regressions[1]).

Empathy?

Posted May 28, 2025 17:25 UTC (Wed) by raven667 (subscriber, #5198) [Link]

I read that with a little sarcasm, which makes more sense to me.

Empathy?

Posted May 29, 2025 22:13 UTC (Thu) by zahlman (guest, #175387) [Link]

In point of fact, `venv` *is* part of the standard library, and pip is bootstrapped by the standard library `ensurepip`.

The main advantage of this setup is that it allows pip to be developed by a separate team, *with a separate release cadence*, which also automatically backports the new features to all the currently-supported Python versions (all the pip team has to do is test on those versions and be conservative about using new Python features).

The downside is that this model encourages copying pip into each virtual environment separately, and considerable know-how is required to manage a single copy of pip and empower it to install cross-environment (even though it *should* be easy and even though there's really nothing about being written in Python that actually causes a problem for this). There's also generally low awareness that pip (since version 22.3) *can* install cross-environment (although it uses a pretty brutal hack for this internally).

As for Setuptools, my understanding is that PEP 517 (and to a lesser extent 518 and 621) was *explicitly* designed to solicit alternative build backends. And there was really never a good way and a good moment to extract "just a" build backend from the project.