Add wheel info subcommand

[killerdevildog]

Implements GitHub issue #639: Add wheel info subcommand to display metadata about wheel files without unpacking them.

Features:

• Shows package name, version, and build information
• Displays wheel format version and generator
• Lists supported Python versions, ABI, and platform tags
• Shows package metadata (summary, author, license, classifiers)
• Displays dependencies and file count/size information
• Optional verbose mode with detailed file listing
• Comprehensive error handling for missing files

Changes:

• Add src/wheel/_commands/info.py with main implementation
• Update src/wheel/_commands/init.py to register new command
• Add tests/commands/test_info.py with comprehensive test coverage
• Add docs/reference/wheel_info.rst with usage documentation
• Update docs/reference/index.rst to include new command docs
• Update docs/user_guide.rst with info command examples
• Update docs/manpages/wheel.rst with info command reference

Addresses #639
See #639

[codecov]

Codecov Report

❌ Patch coverage is 88.23529% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 55.14%. Comparing base (39039c0) to head (e048716).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/wheel/_commands/info.py	89.33%	8 Missing ⚠️
src/wheel/_commands/__init__.py	80.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #669      +/-   ##
==========================================
+ Coverage   52.63%   55.14%   +2.50%     
==========================================
  Files          14       15       +1     
  Lines        1121     1206      +85     
==========================================
+ Hits          590      665      +75     
- Misses        531      541      +10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[agronholm]

Did you no longer need this, or why did you close the PR?

[killerdevildog]

I've faced criticism and harassment on previous pull requests that involved assistance from LLMs. Given that this PR exceeds 330 lines of code, I decided to close it to avoid burdening reviewers with such a large review—even though I'm confident it provides a valid fix for the issue. If you'd like me to reopen it, please let me know. I'm just trying to contribute without being harassed, intimidated, or bullied. Professional criticism is acceptable, but following people around to get PRs closed simply because AI was used to make it function is not.

[agronholm]

Have you faced such criticism in this project, or another PyPA project, or from me? What matters to me is that you can explain what your code does and why. I have rejected AI generated patches in the past because the authors could not explain them to me, and the quality of AI code generated as of today tends to be subpar. But I certainly don't follow people around harassing them for this.

[killerdevildog]

Thanks for clarifying. The issues were in other PyPA projects, not this one or from you. I'm able to explain the code fully—it's my work with some LLM aid for initial drafting, but I understand and tested it thoroughly. Happy to address any questions.

The PR directly implements the feature requested in Issue #639, which asks for a new wheel info subcommand to display metadata (e.g., package name, version, dependencies) for a .whl file or PyPI package without unpacking it. The changes add a new command module, tests, and documentation to achieve this, reading data straight from the wheel's zip structure for efficiency.

[agronholm]

Thanks for the explanation. I'm not currently working on wheel, and I had to yank the last couple releases which makes me apprehensive about any changes I make to the repo. This PR, however, doesn't have such issues as it's completely new functionality, so I will get back to this once I resume work here.

[agronholm]

A changelog entry needs to be added in docs/news.rst and the issues I pointed out need to be resolved.

[agronholm]

Also, the test failure on Python 3.14 needs to be resolved, but that doesn't look like a major issue.

[agronholm]

@henryiii What do you think of the feature in general?

[killerdevildog]

@agronholm
I hadn't taken a look into this since August. Ill fix this pr in the next few days.

[killerdevildog]

Hi @agronholm, thanks for the review feedback. I've pushed a commit addressing all your requested changes:

Removed unused tmp_path_factory — Removed the unnecessary TempPathFactory parameter from test_info_basic() and test_info_verbose().

Replaced try/except with pytest.raises — test_info_nonexistent_file now uses pytest.raises(FileNotFoundError, match="Wheel file not found: nonexistent.whl") to properly test the error case, calling info() directly since the CLI runner catches WheelError internally.

Fixed the Python 3.14 test failure — test_info_help was asserting "usage: wheel info" but sys.argv[0] differs depending on how the tests are invoked (e.g. python -m pytest instead of wheel). Updated the assertion to check for the help content without depending on the program name.

Added changelog entry — Added an entry under UNRELEASED in news.rst referencing issue #639.

All tests pass on both Python 3.12 and 3.14.

[agronholm]

Alright, apart from the pre-commit check failing, the changes look good. Before I merge, I'd like someone else from the PyPA to weigh in on the output of the command.

[agronholm]

I'll solicit outside opinions on the output of the command before merging.

[pfmoore]

This feels like it is bound to get requests for JSON format output. Maybe add that now to avoid churn?

[agronholm]

@killerdevildog The feedback sounds reasonable. Let me know your thoughts.

[killerdevildog]

@pfmoore Thanks — agreed on both points.

Multiple Generator values: the Discourse thread makes it pretty clear the spec wording is ambiguous and historically probably assumed a single generator, but there’s a strong practical case for allowing multiple when a wheel is rewritten by tools like auditwheel/delocate (provenance + debugging regressions). In particular, treating repeated Generator: lines as an ordered history (original builder first, subsequent rewriters after) seems like a reasonable model. I’ll update the wheel info implementation to handle multiple Generator entries rather than assuming only one.

JSON output: I agree it’s likely people will ask for machine-readable output. If you’re happy with it in this PR, I can add a JSON output mode in a follow-up commit; otherwise I can leave it for a separate PR to keep this one narrowly focused.

Let me know if you have a preference on how multiple Generator values should be rendered in the human-readable output (e.g., repeated lines vs. a small “history” block).

[agronholm]

The repeated-lines approach is what I would have assumed as well, so go with that. As for the JSON output, that can be deferred to a new PR.

[agronholm]

Thanks. Looking forward to that JSON output PR.

[killerdevildog]

@agronholm I will work on that this week. Thanks for letting me participate.

[agronholm]

Sorry for taking this long to get around to this. My work on wheel had been paralyzed for a long time due to backlash from releases that attempted to shed obsolete parts such as bdist_wheel. But selectively backtracking on that seems to have worked, as the only issue that was posted since then was about the test dependencies.