Improve error message for wheels with non-compliant versions

[bkurtz]

What did you want to do?
Our organizational development standards prefer that we include a git/vcs hash in most package version numbers. In other environments, this has typically not been problematic, however with python, including a hash in the version number is not PEP440 compliant.

Previous versions of pip have difficulty applying logic (e.g. ~=, >) to these version numbers, but as long as we pin a specific package version, installations would work.

pip install --extra-index-url https://our.local.package.source/artifactory/simple our-package==0.3.0.f038176.11

(apologies, these are internal code and I can't provide a public URL)

Output

ERROR: Exception:
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/pip/_vendor/resolvelib/resolvers.py", line 171, in _merge_into_criterion
    crit = self.state.criteria[name]
KeyError: 'our-package'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 210, in _main
    status = self.run(options, args)
  File "/usr/local/lib/python3.6/site-packages/pip/_internal/cli/req_command.py", line 180, in wrapper
    return func(self, options, args)
  File "/usr/local/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 319, in run
    reqs, check_supported_wheels=not options.target_dir
  File "/usr/local/lib/python3.6/site-packages/pip/_internal/resolution/resolvelib/resolver.py", line 122, in resolve
    requirements, max_rounds=try_to_avoid_resolution_too_deep,
  File "/usr/local/lib/python3.6/site-packages/pip/_vendor/resolvelib/resolvers.py", line 445, in resolve
    state = resolution.resolve(requirements, max_rounds=max_rounds)
  File "/usr/local/lib/python3.6/site-packages/pip/_vendor/resolvelib/resolvers.py", line 310, in resolve
    name, crit = self._merge_into_criterion(r, parent=None)
  File "/usr/local/lib/python3.6/site-packages/pip/_vendor/resolvelib/resolvers.py", line 173, in _merge_into_criterion
    crit = Criterion.from_requirement(self._p, requirement, parent)
  File "/usr/local/lib/python3.6/site-packages/pip/_vendor/resolvelib/resolvers.py", line 82, in from_requirement
    if not cands:
  File "/usr/local/lib/python3.6/site-packages/pip/_vendor/resolvelib/structs.py", line 124, in __bool__
    return bool(self._sequence)
  File "/usr/local/lib/python3.6/site-packages/pip/_internal/resolution/resolvelib/found_candidates.py", line 96, in __bool__
    return any(self)
  File "/usr/local/lib/python3.6/site-packages/pip/_internal/resolution/resolvelib/found_candidates.py", line 20, in _deduplicated_by_version
    for candidate in candidates:
  File "/usr/local/lib/python3.6/site-packages/pip/_internal/resolution/resolvelib/factory.py", line 203, in iter_index_candidates
    version=ican.version,
  File "/usr/local/lib/python3.6/site-packages/pip/_internal/resolution/resolvelib/factory.py", line 145, in _make_candidate_from_link
    link, template, factory=self, name=name, version=version,
  File "/usr/local/lib/python3.6/site-packages/pip/_internal/resolution/resolvelib/candidates.py", line 290, in __init__
    wheel_version = Version(wheel.version)
  File "/usr/local/lib/python3.6/site-packages/pip/_vendor/packaging/version.py", line 298, in __init__
    raise InvalidVersion("Invalid version: '{0}'".format(version))
pip._vendor.packaging.version.InvalidVersion: Invalid version: '0.3.0.f038176.11'

It appears that when installing from wheel, the package version number is parsed using a regex that only matches PEP 440 compliant version numbers, which fails when given a version number containing a git hash.

Additional information
We have found that installing the affected packages from source (by adding --no-binary our-package to the pip command line) acts as a workaround. It is unclear to me why the source installation does not enforce the same version number checks that the binary installation does.

[dstufft]

FWIW you can include a git hash in the version using local version numbers, so something like 0.3.0+f038176.11.

[bkurtz]

Ah, that's good to know and I'd somehow missed that last time I looked through the specs. I'll see if that might be a better long-term solution to our needs (it would be nice to allow other comparison operators besides strict equality).

Still seems like it's a bug that versioning isn't treated the same between binary/source installs.

[dstufft]

Yea it should probably treat them the same between binary and source installs for sure.

One thing to pay attention to is that local versions have some uh "interesting" semantics. If you're just generally using strict equality OR you're using the local version to communicate extra information it'll be totally fine. But it might be surprising if you're trying to use local versions as part of the meaningful part of the version.

[pradyunsg]

--no-binary circumvents all the metadata validation checks today since it's not installing via wheels, but that "loophole" will be plugged, when we drop setup.py install.

[jre21]

When was it decided that pip would only support PEP440 compliant version strings, and why wasn't there a deprecation cycle for this? Given that the pip 10.0.0b1 changelog includes

• Support the installation of wheels with non-PEP 440 version in their filenames. (pip wheel should not create wheels that it will itself deem invalid #4169)

this seems like exactly the sort of change in policy that needs to be communicated to users ahead of time rather than introduced into a release with no fanfare whatsoever.

[pradyunsg]

When was it decided that pip would only support PEP440 compliant version strings, and why wasn't there a deprecation cycle for this?

This is a part of the changes being made as part of the new dependency resolver. The new dependency resolver is stricter across the board with metadata generated by projects. This behaviour has been a part of pip's new resolver which has been in beta for the past few months, and has had several rounds of publicity and communication telling users to test it since we are making significant changes (such as this one!) to it. As noted multiple times across various communication channels, we have a long list of changes toward being stricter about what metadata pip accepts from packages.

There's more discussion about this specific stricter behaviour in another recently-filed issue: #9183 (comment)

[bkurtz]

So, that sounds like we're okay for the short term using source installs, but the writing is on the wall and we need to move toward PEP-440 compliant versioning for all our packages.

WRT warning or lack thereof about this particular change, you all have done a generally phenomenal job of publicizing the need for additional testing of the new resolver. I guess where I went astray was that I'd been thinking of the "new resolver" as one set of potentially breaking changes, and so once I'd tested against those back in 20.2.3 or whatever a couple of months ago, I was assuming it was all bug fixes the rest of the way out, which seems not to have been the case. Ah well!

In terms of this ticket, it seems like:

• the existing behavior with strict version checking of wheels is intentional (not a bug)
• the existing behavior of non-strict checking for source packages is unintentional (arguably a bug) but has plans (elsewhere?) to be addressed by 21.0.

Is there any reason to keep this ticket open, or shall I go ahead and close?

[uranusjr]

Let’s keep this open until at least we provide a better error message for the failure case.

[jakab922]

Can't we make this optional rather than raising an exception? Unfortunately the way we version packages is not conforming with this and we don't intend to change it.