Flit 4 planning

[takluyver]

What major changes do we want for Flit 4.0?

• [x] Remove support for old-style metadata, where a project is described in the [tool.flit] subtables instead of the now-standard [project] table. (but [tool.flit.module], which is used alongside [project], will continue to work).
  • I encourage all projects to specify something like requires = ["flit_core >=3.2,<4"] so we can make changes like this and old packages can still easily be built with 3.x. I know some projects have ignored that and don't specify an upper bound, but hopefully not too many.
• [x] Fail on unrecognised keys in [project] - #505, #506
• ~~[ ] Get rid of flit.buildapi in favour of flit_core.buildapi? #519~~
• [x] Switch the default behaviour of flit build and flit publish to not use VCS info, to get rid of the surprising difference between flit build and python -m build (see discussion on #522 & #625)
  • [ ] Make a tool to generate include & exclude lists for sdists from the VCS? Or a separate way to explicitly make a 'release sdist' by doing git archive or similar? :thinking: - #782

Anything else?

There's still likely to be a 3.10 release first with assorted small fixes and improvements, and possibly more 3.x releases before 4.0.

[takluyver]

Should we get rid of the option to generate a setup.py file in sdists? We turned that off by default in 3.5 (November 2021).

[liZe]

I like all your proposals. I’m still not sure about the best way to keep VCS support for build/publish, but having flit build and python -m build building the same package by default looks like a good idea.

Thanks for your work on Flit!

[z3dev]

Complete keyring support.