Use flit-core to build pip distributions

[notatallshaw]

Fixes #13472

This is a very quick attempt to make a PR to switch to flit-core as pip's build back end, and if there is any missing features pip requires.

There is no plan to merge, at least until, or if, there is agreement among the maintainers.

[notatallshaw]

test_freeze.py::test_freeze_with_setuptool fails on Python 3.9 only, otherwise everything appears to be passing.

[pfmoore]

+1 from me

[pfmoore]

A couple of minor points here.

1. Flit includes license files in the wheel. This isn't a bad thing, of course, and we should be doing it even with setuptools via Switch license metadata to the PEP 639 format #13335 and Why licenses of vendored libraries are not distributed in wheels? #8330. My tests seem to not have the licenses under setuptools, but I'm not going to bother digging to work out why, as it's not relevant.
2. Flit includes everything under the src directory, regardless of what .gitignore says. That means it's important to have a clean checkout - I was getting weird .pyd files in my build, and it took me a long time to work out why they were there¹. It doesn't include __pycache__, though. Unless I've missed something, flit's docs on what gets included in the wheel aren't that great - I've created Document exactly what goes into a wheel flit#747 to see if that can be fixed.

Footnotes

1. Mostly because I didn't spot the .py[cod] pattern in .gitignore 🙁 ↩

[ichard26]

+1 assuming that downstream is OK with it.

This also reduces the time it takes to build pip from source (1.6s to 1s, locally with flit/setuptools cached via --find-links) which is a nice developer UX improvement.

[pradyunsg]

That means it's important to have a clean checkout

FWIW, the next session for building release artifacts does so in a clean temporary working checkout:

pip/noxfile.py

Line 345 in 4bb2bcb

with release.isolated_temporary_checkout(session, version) as build_dir:

[notatallshaw]

Somehow I've got all tests passing without too much difficulty and there is general positive feedback, so I am removing PoC and draft status from PR.

I do think this PR should be open for at least a couple of weeks to get maintainer feedback or anyone else watching pip closely.

[sbidoul]

I compared ¹ the generated wheel in this PR and main, and the difference that stands out is the various LICENCE files that are added in pip/_vendor and subdirectories. There is also pip/_vendor/README.rst that probably should not be in the wheel.

Otherwise this looks good and I'm ok with the change to flit-core.

Footnotes

1. uvx pip-wheel-diff git+https://github.com/pypa/pip@main git+https://github.com/pypa/pip@refs/pull/13473/head ↩

[SpecLad]

I compared the generated wheel in this PR and main, and the difference that stands out is the various LICENCE files that are added in pip/_vendor and subdirectories.

That's actually a flit bug (in my opinion, anyway...); I noticed it myself yesterday: pypa/flit#749.

[notatallshaw]

I should mention that updating test_freeze.py::test_freeze_with_setuptool required taking a different approach to run the test. I don't have a strong understanding of the mechanics of editable installs but I think that the test imported pip via a .pth file, this was throwing an import error as I think flit installs editables via the PEP 660 mechanism?

So if someone is dependent on importing pip in .pth based editable installs it may no longer work?

[ichard26]

So if someone is dependent on importing pip in .pth based editable installs it may no longer work?

It seems like flit-core uses an .pth file for its build_editable implementation anyway, but honestly, I'm not worried about breaking users that are depending specifically on how our build backend implements editable installs. I'm not entirely sure why the freeze test needed to be updated, but I'm going to guess that the order in which the .pth files are executed changed, causing the mock file to execute before the pip source got added to sys.path.

It's mildly annoying that flit decided that the duplicate license files are not a bug (pypa/flit#749), but I'm not going to block this change on it.

I asked the flit team whether they had any objections to us switching over to their backend. No real issues: pypa/flit#751.

Anyway, with my RM hat on, I'm only going to consider merging this if every other maintainer is on board. And even then, I feel that would be possibly premature. We have ~2.5 weeks before pip 25.2 which is not a lot of time.

[notatallshaw]

Anyway, with my RM hat on, I'm only going to consider merging this if every other maintainer is on board. And even then, I feel that would be possibly premature. We have ~2.5 weeks before pip 25.2 which is not a lot of time.

I also think that if this is merged it would be better at the beginning of a release cycle, not at the end.

[pfmoore]

+1 from me on merging, but I agree let’s do it at the start of a release cycle.

[notatallshaw]

Okay, I've cleaned up the commits of this PR, which were quite messy as this started off as an experimental PR.

There is also pip/_vendor/README.rst that probably should not be in the wheel.

This also seems to be a limitation of flit? Adding it to the exclude pattern does not remove it.

[notatallshaw]

Unless anyone objects I'm going to merge this in a few days.

[sbidoul]

Why excluding this from the sdist?

[notatallshaw]

That pattern was added in #4545

It's probably not doing anything anymore? I'll take a look later and remove it if redundant.

[notatallshaw]

Vendoring generates stub files for packages which don't include a py.typed: https://github.com/pradyunsg/vendoring/blob/1.2.0/src/vendoring/tasks/stubs.py#L43-L52

Which puts pyi files here: https://github.com/pypa/pip/tree/25.2/src/pip/_vendor

What's interesting about this, is it doesn't seem to work, at least mypy doesn't find the correct type hints for requests: #13476

I will try and investigate this, but I think the solution will be that we need to update vendoring to stop doing this, or do something more useful?

[notatallshaw]

Vendoring does have some config that allows us to remove or rename these type stub files, which I may take advantage of in a different PR: https://github.com/pypa/pip/blob/25.2/pyproject.toml#L182

[sbidoul]

Thanks for the investigation. This does not sound blocking for this PR anyway.

[notatallshaw]

Thanks all, I've merged so it's hopefully well verified before 25.3. I'm happy to revert if we find an intractable issue.