Ability to write Requires-External metadata

[rmorshea]

This may be out of scope for the project, but I'd like to be able to write to the Requires-External field of the package METADATA. If this isn't a feature that can be provided out of the box, I was already planning to wrap flit_core, so if there's at least some sanctioned way to overwrite the internal behavior of Metadata.write_metadata_file or some other behavior of common.* functions that would be great.

[takluyver]

My initial inclination is to say it's out of scope - I'm not aware of any tools that consume it, and for telling humans about external requirements, I think you're better off describing them in free text in the description. But feel free to make a case for it - maybe there's some reason to use it that I'm not aware of.

Be aware that the only public interfaces to Flit are the PEP 517 API (flit_core.buildapi) and the command line interface. Everything else is implementation, and can be changed with no deprecation period or warning in the release notes, even in minor versions. Maintaining an extensible API is a bigger challenge that I didn't sign up for. 😉

[bpabel]

Since flit_core is responsible for writing the package metadata, wouldn't it be in scope to support all of the core metadata fields?

[rmorshea]

@takluyver I was planning on using it to specify Javascript dependencies that need to be installed (e.g. for a Jupyter widget) that would be consumed by a downstream installer. So instead of having to run:

pip install my-widget
jupyter labextension install client-for-my-widget

You could simply run:

jupyter labextension install my-widget

Where jupyter labextension install is aware of the Requires-External metadata so it can pip install the package and then automatically install the client.

Admittedly though this is a niche use case, and as much as I wish this could be added, it looks like setuptools opted not to include it in their API either: pypa/setuptools#631 (comment)

[rmorshea]

If this field isn't natively supported by flit I can see two options that would allow me to move forward:

1. flit_core could define a generic API that would allow me (or others) to manipulate the package files before build. Something like:

# on __enter__ prepare build files normally
with flit_core.use_wheel_build() as build_dir:
    # user has access to all prepared files just before the wheel is built
    ...
# on __exit__ build the wheel file using files from build_dir

2. I could pin the version of flit_core I use until I'm able to confirm there are no breaking API changes in the next.

[rmorshea]

@takluyver thoughts on the PR by @bpabel? Alternatively, the above API suggestion doesn't really expose any internal functionality, just the temporary directory flit_core builds the wheel/sdist from. In that way any errors that arose from a user's manipulation of the files in the build_dir would only result from an incorrect implementation of standards by the user or by flit_core.

[rmorshea]

@takluyver any further thoughts on this issue and corresponding PR?