Unhandled exception if version is not determinable

[HenningUe]

Description

Packages with incomplete version data cause an unhandled exception, see stacktrace below

Expected behavior

A comprehensive error message that tells the user which package is incomplete and what exactly is missing.

pip version

25.1.1

Python version

3.12

OS

Windows

How to Reproduce

1. Setup a local package with pyproject-toml. Leave out the version info
2. Inside the package put some dummy code under "src"
3. Create a venv inside this package, e.g. ".venv"
4. Call pip install .

Output

Looking in indexes: https://pypi.python.org/simple
Requirement already satisfied: pip in c:\work.venv\lib\site-packages (25.1.1)
ERROR: Error while checking for conflicts. Please file an issue on pip's issue tracker: https://github.com/pypa/pip/issues/new
Traceback (most recent call last):
File "C:\Work.venv\Lib\site-packages\pip_internal\commands\install.py", line 587, in _determine_conflicts
return check_install_conflicts(to_install)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Work.venv\Lib\site-packages\pip_internal\operations\check.py", line 116, in check_install_conflicts
package_set, _ = create_package_set_from_installed()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Work.venv\Lib\site-packages\pip_internal\operations\check.py", line 58, in create_package_set_from_installed
package_set[name] = PackageDetails(dist.version, dependencies)
^^^^^^^^^^^^
File "C:\Work.venv\Lib\site-packages\pip_internal\metadata\importlib_dists.py", line 175, in version
return parse_version(self._dist.version)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Work.venv\Lib\site-packages\pip_vendor\packaging\version.py", line 56, in parse
return Version(version)
^^^^^^^^^^^^^^^^
File "C:\Work.venv\Lib\site-packages\pip_vendor\packaging\version.py", line 200, in init
match = self._regex.search(version)
^^^^^^^^^^^^^^^^^^^^^^^^^^^

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[notatallshaw]

Thanks for the report, I agree it would be better to have a nicer error message here.

Please be aware pip is a volunteer project, so it would require someone to decide to spend time on this to submit a high quality PR.

[sepehr-rs]

Hi @HenningUe,

I attempted to reproduce the issue you mentioned, but I'm not experiencing the same behavior on my end. I followed all the steps you outlined, testing on both a Linux and a Windows machine, and here's the result I consistently get:

Processing /tmp/pyerror
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  error: subprocess-exited-with-error

  × Getting requirements to build wheel did not run successfully.
  │ exit code: 1
  ╰─> [36 lines of output]
      ...
      ValueError: invalid pyproject.toml config: `project`.
      configuration error: `project` must contain ['version'] properties
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.

Let me know if there's a specific detail or environment I'm missing that might help reproduce your bug more accurately.

[ichard26]

@sepehr-rs it's easier to reproduce the bug by manually corrupting the installation metadata after pip installing something. Say you install six 1.16. If you dig into the environment's site-packages folder, open six-1.16.dist-info/METADATA and remove the Version: 1.16 line, you should encounter the same crash reported here.

While this is a case of bad/corrupted metadata, it does seem to happen IRL given the volume of reports similar to this one.

[sepehr-rs]

@sepehr-rs it's easier to reproduce the bug by manually corrupting the installation metadata after pip installing something. Say you install six 1.16. If you dig into the environment's site-packages folder, open six-1.16.dist-info/METADATA and remove the Version: 1.16 line, you should encounter the same crash reported here.

While this is a case of bad/corrupted metadata, it does seem to happen IRL given the volume of reports similar to this one.

Thanks for the detailed explanation @ichard26 !
I followed your steps and tested a bit further — it looks like the only unhandled metadata field that causes a crash is the Version field.

Interestingly, when the Name field is missing from the METADATA file, pip doesn't crash but shows a warning message. For example:

(venv) sepehr@debian:/tmp/pipe$ pip show six
WARNING: Skipping /tmp/pipe/venv/lib/python3.11/site-packages/six-1.17.0.dist-info due to invalid metadata entry 'name'
WARNING: Package(s) not found: six

(venv) sepehr@debian:/tmp/pipe$ pip list
WARNING: Skipping /tmp/pipe/venv/lib/python3.11/site-packages/six-1.17.0.dist-info due to invalid metadata entry 'name'
Package    Version
---------- -------
pip        23.0.1
setuptools 66.1.1

Also, pip seems to skip over other malformed metadata info ( like Author, Author-email, etc. ) gracefully, without raising an error or even a warning.

So, my question is: should we treat the Version field the same, by skipping over it silently, or raise a warning instead ?

[pfmoore]

Version and Name are the two mandatory metadata fields, so my preference would be to do the same as Name, and warn.

[sepehr-rs]

Version and Name are the two mandatory metadata fields, so my preference would be to do the same as Name, and warn.

Sounds good! I’ll take a look at the issue and send over a PR soon.

[sepehr-rs]

Hi @pfmoore,

I initially attempted to patch the issue by adding a simple try/except block in version.py around line 200. While this prevented the crash, I'm now seeing some odd behavior in pip. After applying the patch, running pip list shows the affected package's version as None. However, pip freeze seems to correctly pick up the version, presumably from the .dist-info directory. However, this inconsistency doesn't happen for the name value (i.e., raises a warning and skips the package).

While investigating, I came across this note in @ichard26’s blog post on pip 24.2:

On slower systems, the performance improvement will be greater. This uplift was achieved by optimizing pip’s importlib-based metadata backend to read package names and versions from the installed metadata directory names. Previously, pip would read the name and version from the METADATA file, which is slow as it involves an extra file read and invoking an email header parser.

Given this, I was wondering: if the METADATA file is malformed, should pip try to fall back to reading the version from the .dist-info directory name, like it seems to do in pip freeze? And is there a reason this fallback doesn't appear to apply similarly for the name?

I’d really appreciate any guidance or suggestions on how best to handle this.

Thanks!

[sepehr-rs]

Hi @pfmoore & @ichard26, I just wanted to check in and see if you have any thoughts on the matter I mentioned above. I want to align with your expectations before proceeding with a PR. Really appreciate your time :).

[notatallshaw]

Hey @sepehr-rs we will take a look, but just be aware that we're all very much doing this in our spare time, so no need to ping after just a few days, even if I put this on my queue of things to review right now I wouldn't have chance to review this approach until probably September. I think other active maintainers are also quite busy with real life things this summer.