Pip would like to use flit-core

[ichard26]

Hello @pypa/flit-committers,

The pip project would like to switch our build backend to flit-core as setuptools has demonstrated a surprising amount of instability in the past year. I'm opening this issue to simply give y'all a heads up that we are considering this switch. I have no concerns about the backwards compatibility or stability with flit-core that would make it unsuitable for pip. If you have any objections, please let us know.

See also: pypa/pip#13472

Thanks :)

[takluyver]

Thanks for the heads up!

I see that on the linked issue the infrequency of major releases is cited as a point in favour of Flit. I feel like I should mention two things in connection with that. First, it may be as much to do with the limited maintainer time as any deliberate effort for stability - although there are a few people with commit access, it's mostly still me merging things and making releases, and Flit is not really part of my day job, so I'm not always quick to respond. On the plus side, being pretty simple in what it does, it seems to largely tick over OK despite that.

Second, I am actually planning to do a new major release (4.0) soon ™️, so long as I can find some time to work on it. There are two specific places where I'm planning to break backwards compatibility with this:

• Getting rid of the old-style metadata in a [tool.flit.metadata] table, which was superseded by the standardised [project] table. This shouldn't be an issue for any project adopting Flit now, assuming you do the obvious thing and use the new standard.
• flit build currently defaults to using information from git to determine what goes in the sdist, but using Flit as a backend to e.g. python -m build doesn't. Using git this way is convenient, but I now think it's a bit too clever, and I'm planning to switch it off by default for flit build. This shouldn't change anything if you're not using the flit CLI directly.

If those caveats don't put you off, I have no objection to pip using flit-core. It would be the most prominent project to use Flit, but a number of core packaging projects like build and installer are already built by Flit, so I think it's already somewhat battle tested. 🤞

If pip adopting flit-core does lead to a slew of new issues, I'd appreciate some extra eyes to sort through them and figure things out. But I don't think that's too likely.

[ichard26]

Neither of the planned backwards incompatible changes for flit 4.0 should affect us. We are using modern metadata and use build to build our distributions anyway.

First, it may be as much to do with the limited maintainer time as any deliberate effort for stability

Heh. I get that. Pip is pretty much in the same boat right now. Technically the pip core team is quite large, but in practice, there are at most 1-3 maintainers available at any given moment.

Assuming no one screams bloody mary in the next two weeks, we'll switch over to flit-core after pip 25.2 is released. That will give us three months for the change to live on main and be "tested" by downstream which is more than enough time for someone to yell at us if needed :)

If pip adopting flit-core does lead to a slew of new issues, I'd appreciate some extra eyes to sort through them and figure things out. But I don't think that's too likely.

It's moreso been identifying existing issues. You can blame our investigation into switching to flit for some of the recent activity. But that sounds good. I'd be happy to help if time permits 👍

Thanks for getting back to me so quickly!

[notatallshaw]

FYI this is now merged into main pypa/pip#13473