-
Notifications
You must be signed in to change notification settings - Fork 153
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Several fixes to
WHEEL
metadata handling (#588)
* cli: Add missing return type annotations * bdist_wheel: Remove dead code for postprocessing WHEEL line endings The default policies of Message and BytesGenerator always produce LF line endings, so there's never a CRLF to match. If there were, the existing code would have incorrectly replaced CRLF with CR, and then test_wheelfile_line_endings() would have failed. * cli: Fix removing build tag with `wheel pack --build-number ""` There's an existing test for this case, which verifies that the original build tag is removed from the wheel filename and is *not* removed from the WHEEL metadata. Presumably this is not what was intended. BUILD_NUM_RE assumed that it would only match at end of file, but there's at least a newline in the way. Fix it, and the test. * cli: Allow removing build tag with `wheel tags --build ""` For symmetry with `wheel pack`. The functionality works already; we just need to fix the command-line validation. * test: Restructure test_pack() around email.message.Message We're about to change pack() to emit WHEEL metadata with LF-terminated lines and a trailing blank line. In some test_pack() parameterizations we expect to see the original WHEEL file from the test fixture, and in some, a modified one. Handle the difference by comparing WHEEL contents parsed with email.parser, instead of byte strings. * cli: Remove hand-rolled WHEEL parsing/mutation code The PyPA Binary Distribution Format spec says the WHEEL metadata file is "in the same basic key: value format" as the METADATA file. METADATA in turn is governed by the Core Metadata Specifications, which say: "In the absence of a precise definition, the practical standard is set by what the standard library email.parser module can parse using the compat32 policy." wheel.bdist_wheel accordingly uses email.generator.BytesGenerator to generate WHEEL, but the CLI `pack` and `tags` commands opt to hand-implement WHEEL parsing and mutation. Their mutation functions, set_tags() and set_build_number(), append any new headers to the existing WHEEL file. Since WHEEL tends to have a trailing blank line (separating the headers from the nonexistent body), the new headers end up in the "body" and are ignored by any tool that parses WHEEL with email.parser. In addition, both functions assume that WHEEL uses CRLF line endings, while bdist_wheel (and email.generator with the compat32 policy) specifically always writes LF line endings. This turns out okay for set_tags(), which rewrites the whole file, but set_build_number() ends up appending a CRLF-terminated line to a file with LF-terminated lines. Fix all this by removing the hand-written parsing/mutation functions in favor of email.parser and email.generator.
- Loading branch information
Showing
8 changed files
with
63 additions
and
102 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters