-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Add new make_wheel test helper #7651
Add new make_wheel test helper #7651
Conversation
ed382f5
to
49f40c1
Compare
Bump. |
49f40c1
to
4f78cc8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name of this helper (and PR's title) communicated something very different from what this PR is -- I thought it was adding a helper for the WheelBuilder
class.
I suggest renaming the helper to generate_wheel
.
Overall, this sounds like a great idea to me. ^>^ I'd thought of something similar to this, to be a part of the "improve pip test suite" GSoC project ideas -- which tells me that it's probably a good idea, because two people came up with something similar independently. :) My thought was to include aggregating all the wheels in tests/data and |
@pradyunsg there is no WheelBuilder class anymore ;) |
How about |
Which contributed to why I was surprised by the naming here. :)
LGTM. |
As we introduce stricter metadata parsing, we will need to ensure that the wheel files used in our tests are compliant (except in the specific way that we're testing against). Currently we have a large number of test cases relying on undocumented or under-documented wheel files that have various inconsistencies (incorrect name, missing fields) that are unrelated to the features actually under test. With a new wheel builder helper function, we will be able to replace all of our instances of pre-built wheel test fixtures with dynamically-generated files in code that are correct by default.
4f78cc8
to
667dc39
Compare
Updated to |
IIUC, we'd want to switch over to this more-and-more in our tests, especially the ones that depend on |
That's the plan. I already have a fair number converted and I can issue PRs for them later today. |
Great! BTW, @chrahunt: the merge commit for this is the 9000th commit on |
While updating and trying to make our wheel metadata parsing stricter, I noticed
that a large number of our test wheels were noncompliant for various reasons (missing fields, inconsistent metadata).
After a closer look, it's actually pretty bad! The majority of our test wheels are
not automatically generated, many lack documentation, and the ones that are documented
may have documentation in one of several places.
To make it easier to generate compliant-by-default wheels, I've added a helper function
(
tests.lib.wheel.wheel_builder
) for generating wheel files and toggling various properties of them and a result class (tests.lib.wheel.WheelBuilder
) that lets us choose at the call site how we want to consume it.At a high level this will give us several benefits:
a "regular" wheel file
needing a bunch of manual investigation and effort
speed up unit tests that need an actual wheel, but not necessarily a wheel file
To test the completeness of the interface I have locally converted most of our tests, so if this looks OK I can follow up with those changes.