The project repository had no activity in the past several months (only 2 commits in July and nothing afterwards), and all bug reports since July hang with the “Needs Triage” tag, without any attention from the maintainers (the last activity was about some suspicious merging of unused code with problematic licenses). Since PyPA has a rather aggressive approach to deprecating and quickly removing older mechanisms still used by many third-party projects, this lack of activity might be a relief, :–) but at the same time we might be stuck in a situation when the official packaging tool emits frightening but outdated warnings about older mechanisms while not implementing the newer mechanisms correctly. Can anybody clarify the situation?
This isn’t the right place to discuss the status of a third-party project. That said, three months is far too early to be asking ‘is X abandoned’.
A
I agree, discussions of abandonment are best raised on the the project’s issue page directly, and a 3 month break for a very mature library is not particularly long.
While setuptools has been a pillar of the Python packaging ecosystem, I suggest you take this opportunity to consider if is still the best build backend tool for you, coming from setuptools I usually recommend users look at flit for simplicity or hatchling for extensibility.
Many build backends are part of a project management tool but, due the design of PEP 517 compliant build backends, they can be used with or without the associated project management tool.
Here are some of other backends widely used:
-
flit-core for simple pure-Python packages
-
hatchling extensible for general projects
-
uv-build native uv backend for fast, zero-config builds
-
pdm-backend PEP-compliant backend used by PDM
-
poetry-core used by Poetry for dependency-managed projects
-
maturin for Rust extension (PyO3) packages
-
meson-python for C/C++ or mixed-language extension builds
-
scikit-build-core for CMake-based compiled extension projects
The pyopensci organization has a nice overview of alternative backends here:
My impression was that PyPA is very closely affiliated with Python. The main concern about Setuptools is that, contrary to the claim that “Python has a ‘batteries included’ philosophy”, the built-in distutils module was removed explicitly in favor of Setuptools.
I’ve seen some mentions of advisory from and funding by PSF in the repository issues and discussions, so I thought that asking here would be appropriate.
Could you please explain how this will help when the project maintainers don’t react even to security-related issues?
I would agree if the project was not moving far too quickly before June (for example, see Proposed new policy: breaking changes get batched for annual cycle · pypa/setuptools · Discussion #4927 · GitHub about 10 major versions per year) and was not deprecating features with just one-year grace period (some of which, by the way, have already expired or will expire later this month).
Also, thanks to everybody for the suggestions to stay away from Setuptools, but this does not really answer the original question. Moreover, I don’t see anything besides Setuptools in Python’s documentation about Building C and C++ Extensions; neither PyPA’s cibuildwheel nor Cython (this one is really “third-party”, but nonetheless) even mention flit or hatchling; and some other suggested alternatives actually depend on Setuptools.
All of this sounds like really solid action items for improving documentation. I’ll add it to my personal list to try to contribute a Cython example using meson-python (my personal favorite).
PyPA isn’t a monolithic organization of projects, it’s working group of separately maintained Python packaging projects that have agree to a user guide and follow a governance model to publish standards: Python Packaging Authority — PyPA documentation
PyPA as a whole doesn’t make choices about individual projects, that’s up to those project maintainers.
That would be something to take up with the PSF and Core Development team. There is a long history to why package tooling is not included in the standard library.
Setuptools was the go to replacement for a long time, but since PEP 517 was passed it is a lot easier to use other build backend, and now there are a good selection of them.
Because you’re best discussing it where the setuptools maintainers are most likely to reply, and failing that at least with other setuptools users.
I’ll add it to my personal list to try to contribute a Cython example using meson-python (my personal favorite).
There’s one Meson example hidden in our Limited API documentation. But we’d definitely welcome improvements here from people who have actually used these tools
Because you’re best discussing it where the setuptools maintainers are most likely to reply, and failing that at least with other setuptools users.
More importantly, what is the problem here?
- Is there a particular issue that you need a fix for? You could try submitting a PR yourself.
- Do you have support concerns? As setuptools is a volunteer project, there are no support guarantees anyway.
- Are you trying to decide on what to do if setuptools is abandoned? Then the answer is that you will need to change to another build backend. People have offered advice on that already.
- Are you offering to help support setuptools? You can do that anyway. Start working on issues and raising PRs. If nothing gets merged, and there’s a large backlog of important fixed that needs a maintainer to merge, then start asking for help.
But as others have said, 3 months of quiet is far from being a sign of abandonment. You have commented yourself on the pace of setuptools change. A 3 month quiet period should be a relief
Maybe the maintainers can’t sustain that pace any more than their users can.