Should Flit move into PyPA maintenance?
This has come up before, but it seems especially topical now. The
pep517 package (which I maintain within PyPA) is built with Flit, as is @pradyunsg’s
installer package, and
build is considering switching to Flit. These are the low level tools which you can use to build & install everything else, so if
build does make the switch,
tomli will be the first things you need if you want to build everything up from source (see Flit’s docs page on boostrapping).
I’m also conscious that I’m not fully keeping up with issues & pull requests on Flit. It’s pretty simple, which limits the changes it needs, and it’s up to date with things like PEP 621 and 660, but requests for things like namespace packages are stalled. I wouldn’t abandon it if it became a PyPA project, but maybe it would mean I’m less of a bottleneck.
If PyPA did adopt Flit, I’d like to avoid any suggestion that it’s the ‘official’ or ‘standard’ tool for creating & publishing packages. I don’t want what happened to pipenv. Poetry probably offers a better developer experience for many packages, setuptools can do many things that Flit can’t, and I expect that packages with complex build steps will use more powerful backends (e.g. this work for scipy). The only particular advantage of Flit is that it’s more or less the simplest possible packaging backend (for PEPs 518, 517, 621, 660…).