I'd certainly be OK with having the strict option by default, and I think I'd go one step further and not make an option at all.

I just remembered we already have an environment variable FLIT_ALLOW_INVALID as an escape hatch for metadata that fails validation. That applies to a separate validation step which occurs after loading the config proper, but I don't know if that distinction is really important. Maybe that's close enough that we could reuse it for this, giving users a way round the problem if there is an unknown key, without needing another option? 🤷

Ok, let me see. I want to test if the FLIT_ALLOW_INVALID pass the pip install -e . and python -m build. Those are my main concern. As things get more and more built in isolated envs, I'm still sort-of thinking that a value that is part of the pyproject.toml sort of make sens.

That's a good point. But I think a value in the pyproject.toml is perhaps not ideal, because that's controlled by the maintainers of the package, not by the people who might be trying to build it. Of course, the people downstream could patch pyproject.toml to use this option... but then they could also patch it to remove the extra keys.

I agree, I just don't see a reason to set/unset it outside of pyproject.toml, cause if there are extra keys then the maintainers should be aware of them.

(I actually don't see a reason to unset failing on non-existing key at all unless there are new keys and an old versions of flit...).

I want to test if the FLIT_ALLOW_INVALID pass the pip install -e . and python -m build.

I can confirm that it will work. :)

I use the same mechanism (environment variable) in another build backend: https://github.com/pradyunsg/sphinx-theme-builder/blob/97bd61c3a441341cd33c5af11c3264226c297b9e/src/sphinx_theme_builder/_internal/nodejs.py#L99

Thanks @pradyunsg . 🙂

I'm also OK with just erroring on unknown keys with no escape hatch - I think the PEP 621 support is new enough that we can probably get away with this, and we can always add an escape hatch if it turns out to be an issue. If we do want an escape hatch, the environment variable is my preference.

It appears that at least one package has made it to PyPI with a misspelled key - pandas_dataframe_convert==0.2 has dependancies instead of dependencies.

This is probably a prompt to get this fixed quickly. But maybe also that we do need some kind of escape hatch to let such packages be built. 😕

Technically incorrect but still largely working. Given what it is, I'd guess a lot of users have pandas installed anyway.

It was only up for a matter of hours before a new release corrected the issue, so in this case we'll probably get away with breaking the older release. But it does show that real people are hitting the issue and managing to upload packages to PyPI.

Technically incorrect

The best kind of incorrect.

My current thinking is that we'll make unknown [project] keys an error for Flit 4.0. I encourage all projects to specify an upper bound (currently <4) on the version of flit_core they build with, so that we can make changes like this without breaking existing packages.