Flit 4 planning

[takluyver]

What major changes do we want for Flit 4.0?

• 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.
• Fail on unrecognised keys in [project] - Consider making it possible to fail on unknown keys in [project] table #505, Add option to fail on unknown keys. #506
• Get rid of flit.buildapi in favour of flit_core.buildapi? Emit warnings when flit.buildapi is used #519
• 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 Discussion: future shape of the 'flit' command #522 & Add --use-vcs and --no-use-vcs flags for build commands #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? 🤔

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.