Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The PEP 517 build_wheel hook should make use of the metadata_directory argument #389

Open
uranusjr opened this issue Jan 30, 2021 · 3 comments

Comments

@uranusjr
Copy link
Member

Quoting PEP 517:

build_wheel

If [metadata_directory] is provided, then build_wheel MUST produce a wheel with identical metadata.

However, the implemention in flit-core simply drops the value of metadata_directory sliently, and builds the wheel metadata directly from pyproject.toml. While this is a perfectly valid implementation, Flit should at least verify the produced wheel indeed contains identical metadata to those provided with metadata_directory.

@uranusjr
Copy link
Member Author

See also pypa/setuptools#1825 and python-poetry/poetry#1078.

@takluyver
Copy link
Member

The reasoning here is that Flit doesn't support any config options from the outside that would alter the metadata, so if you give it the same input files, you'll get the same metadata. I assume the frontend can only pass a metadata created from the same source directory, though that's not entirely explicit in the spec.

Of course it could check that the metadata from the directory is the same as the new metadata it's making, at the cost of some extra complexity. But if it's not, then what? Should it error out and refuse to build a wheel? What practical problem does this solve?

@uranusjr
Copy link
Member Author

It would potentially prevent a faulty package from being installed. For example, say Project A 1.0 incorrectly claims itself 1.1 during prepare_metadata_for_wheel. Project B depends on A!=1.0. A dependency resolver resolving a locally source tree of Project A (i.e. no version available otherwise) would incorrectly detect that Project A is compatible with B, while in reality it is not. I chose version as an example since it is the easiest to understand, but the same apply to various metadata fields leading to more difficult-to-debug situations.

Another potential scenario is when users want to write intree hook to extend flit, as described by Chris Hunt in python-poetry/poetry#1078. Even something as simple as raising an exception when metadata do not match would greatly improve things and point such users to the right direction, even if that direction is “don’t do this, Flit does not support it”.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants