Option to not fallback for wrappers.prepare_metadata_for_build_wheel

[chrahunt]

Currently prepare_metadata_for_build_wheel builds a wheel if the hook is not implemented by the given backend.

It would be nice to be able to disable the automatic fallback behavior. The specific use cases are:

1. More consistent user experience - a package that uses a backend that does not implement preparing_metadata_for_build_wheel may show "Preparing wheel metadata" for a long time and "Building wheel for (PEP 517)" for a short time. Another package that does implement preparing_metadata_for_build_wheel would show the opposite behavior.
2. When refactoring pip, we would like to align the actual state of the project on disk with the type representing that project in memory. See pypa/pip#6607 (comment) for reference. Specifically, a "Local modern project" may have its metadata queried but if that fails then we want to know about it and explicitly advance the state to a "Local wheel" by building a wheel. Mocking this behavior for unit tests is very straightforward, but those sorts of tests get further from the truth if the library is keeping a wheel off to the side.

[takluyver]

It seems reasonable to have a way for the application to handle that case rather than the library. Something like prepare_metadata_for_build_wheel(..., _allow_fallback=False)? Then it would probably throw a new HookMissing exception?

Should we do the same for the other optional hooks (get_requires_for_build_*) while we're at it? Or are the fallbacks for those straightforward enough that it's OK for the library to always handle them?

[chrahunt]

Something like prepare_metadata_for_build_wheel(..., _allow_fallback=False)? Then it would probably throw a new HookMissing exception?

I think that looks good. Build-backend-specific arguments should be going into config_settings and presumably an _-prefixed argument wouldn't be officially added PEP 517 (or a future PEP), so very little chance of a conflict or regret later.

Should we do the same for the other optional hooks (get_requires_for_build_*) while we're at it? Or are the fallbacks for those straightforward enough that it's OK for the library to always handle them?

I can't think of a use case for making the same change for the other hooks, so I would leave them as-is. If someone wants them all they need to do is ask. :)