setuptools is the library that has long handled building and packaging Python projects. Its own documentation describes it as “a fully-featured, actively-maintained, and stable library designed to facilitate packaging Python projects”, letting developers share reusable libraries and applications that can be installed via pip and distributed through PyPI (https://setuptools.pypa.io/en/latest/). It grew out of and extended Python’s original packaging library, distutils, adding features that distutils lacked.
For most of Python’s history, a project was packaged by writing a setup.py script that called into setuptools. That script declared the project’s name, version, dependencies, and the files to include, and running it produced the distributable artifacts. The setuptools project also shipped easy_install, an early command for downloading and installing packages and their dependencies, which predated and was later largely superseded by pip.
Because nearly every project used it, setuptools became the de facto standard interface for building Python packages. PEP 517 records the consequence: while distutils and setuptools had limitations, “it’s very difficult to use anything else, because distutils/setuptools provide the standard interface for installing packages expected by both users and installation tools like pip” (https://peps.python.org/pep-0517/). In other words, setuptools was not just a tool but a gatekeeper that every other tool had to work through.
Later standards loosened that hold. PEP 517 and PEP 518 introduced a build-backend abstraction so that tools such as Flit, Poetry, and Hatch could build packages without going through setuptools, with the stated goal “to get distutils-sig out of the business of being a gatekeeper for Python build systems” (https://peps.python.org/pep-0517/). setuptools remains widely used and is itself now one such backend, but it is no longer the only road to a built Python package.