Are setuptools abandoned?

Packaging User Feedback
1

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?

2

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

9 Likes
3

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:

6 Likes
4

The pyopensci organization has a nice overview of alternative backends here:

1 Like
5

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.

5 Likes
6

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).

2 Likes
7

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.

8

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

9

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 :slightly_smiling_face: Maybe the maintainers can’t sustain that pace any more than their users can.

6 Likes
10

I appreciate you giving your opinion, because there way too many backends. I’ve spent two weeks researching backends so I can switch from setuptools, I just don’t have time for this, I can’t try them all, and I really don’t care which I use as long as it works.

1 Like
11

I generally recommend hatchling in that case, it generally just works, but you can do lots of configuration for specific requirements. I switched all my work projects to hatchling two years ago and never had an issue.

For the most simplicity and stability flit-core is probably the best, but because it’s so simple there are things you can’t customize, I switched pip to that in the latest release, and we had to accept the produced wheel wasn’t exactly the same as the setuptools one.

5 Likes
12

And if you need to build extensions, IMO meson and meson-python do a great job.

1 Like
13

Pull requests have been stalled for over a year, actually. There are quite a few simple pull requests with things like dependency bumps and typing updates going back at least a year. (I’d really like the built-in types, types-setuptools broke me a couple of days ago!). Though @jaraco and @abravalheri are still around, and I don’t think it’s “abandoned”; critical fixes likely will make it in. I don’t envy having to maintain it, every attempt to improve anything breaks someone.

If we can get a new packaging release out, then there might be some movement to ship new PEP support in setuptools too. :slight_smile:

You don’t need to research alternatives, just use hatchling. :wink: It’s 3x faster, simpler, way better error messages (no nested distutils layers of classes!), and just as extensible (though with a designed API, not hacking the internals like setuptools!). The only reason to use flit-core is if you are working on one of hatchling’s dependencies, or need a build backend that has zero dependencies (like for boot-strapping). 99% of the time, that’s not the case. Flit-core is also fast and simple, but much harder to configure file inclusion correctly (use check-sdist to see if you forgot files if you use flit-core).

Though the other build backends are just fine; pdm-backend is also excellent, and these days even poetry-core works fine. You won’t be dissapointed with them, and switching is easy since they all have the same metadata configuration.[1] The reason there are so many is most frontend tools (uv, poetry, hatch, pdm, flit) have a backend, and if you use both together you get some benefits like improved performance (or in flit’s case, a different build result, which is terrible IMO). For example, if you use uv_build with uv, then it just builds the files in Rust without downloading packages or running Python at all; this is nice if you are using uv run.

If you need to build C/C++/Fortran/CUDA extensions, try scikit-build-core (or hatchling with the scikit-build-core plugin!). It’s much more configurable than meson-python, simpler to get started, and is built on CMake, which is the most popular build tool for those languages, and well supported.

  1. Most follow PEP 621. ↩︎

6 Likes