Henry Schreiner

Actually, how much validation is done on `project.dynamic` outside of the build backend? One option would be to simply allow a table for `project.dynamic`, with `[project.dynamic] version={}` being treated identically...

For plugin metadata, possibly not. There's a clear use case for building - `ninja`, `cmake`, `patchelf`, and `swig` are all examples of things that you can't just "add" to the...

I'm not as strongly in favor of the shortcut as I thought I'd be, actually. ```toml [project.dynamic] license = "mylicenseapp" ``` To me, that looks a little like you are...

I tested this with flit-core. By disabling one line (the check to make sure that "dynamic" is a list), it builds - both flit and pip are happy with it,...

That's fine (same is true with `flit-core` - and `scikit-build-core`/`meson-python`, too, since `pyproject-metadata` strictly validates) - the build backend has to be updated to support this proposal. But that's fine...

The rule is "you can statically infer x from pyproject.toml if it exists and unless x is listed in dynamic" - and that rule remains the same in Python, "in...

Is it really necessary to pass the parsed pyproject.toml dict in? The tool should be able to find it (using the same procedure as the PEP 517 build hook calling...

I think the existing plugins are either parsing the file already, and it's just just a simple load (backends should not be passing a modified pyproject dict), so it's pretty...

Well, a TOML library requirement (for reading, anyway) will simply go away in a few years, and is already a very lightweight dependency. My general stance is any conditional backport...

It's a `if sys.version_info` block, that is. Backports should always be based on `sys.version_info`, not `try`/`except`. Then readers know why it's there and when to get rid of it -...