Installation fails if a package publishes a late built distribution

[n1ngu]

Update

Waiting on pypa/pip#11692

---

Issue description

• Given a former release of a project that did not initially include a built distribution for your target platform
• When a built distribution is published days or years after Pipfile.lock was generated
• Then installation fails because the preferred built distribution does not match any of the hashes listed in the lockfile

E.g. see https://gitlab.com/doctormo/python-crontab/-/issues/103

python-crontab 2.6.0 was released on Oct 19th, 2021 but only a source .tar.gz distribution. Yesterday Dec 20th, 2022 a built .whl distribution was pushed for the same 2.6.0 version. Because the wheel is preferred by default, installation fails.

Expected result

Installation should fallback to the less specific distributions whose hashes are listed in the lockfile, up to the source distribution.

Actual result

Installation fails.

Steps to replicate

As this is a time-sensitive issue, coupled with artifacts published in the python index under use, I guess the easiest reproduction steps is just to manipulate an existing valid Pipfile.lock removing the hashes of distributions prebuilt for your platform, or leaving only the .tar.gz hash.

[0xdade]

I wrote in some detail about this issue last night after we resolved it at work.

I think the biggest problem with this issue is that pipenv sync will now fail on any revision of any code using this package between between Oct 19th 2021 and Dec 20, 2022. This creates huge problems for bisecting other issues in your code, building old versions, etc, and makes the repeatability gained by Pipfile.lock/pipenv sync basically moot.

I'm of the opinion that publishing a new wheel for something that was previously only an sdist is a good thing for developers to do, and that since I originally installed with an sdist, I was, at least on some level, okay with installing from the sdist. The presence of a wheel on PyPI should not supersede the validity of the hash I have for the sdist in my Pipfile.lock. The sdist hash is still valid, there's still an avenue of installing this package.

I think a hard error should only be surfaced when the hashes in your lock file are no longer available for installation -- otherwise I'd be very happy to see a loud warning, much the same as the current warning that fails the build, except, you know, without failing the build. Or at least a CLI option to say "As long as an installation candidate is available that is in my Pipfile.lock hashes, continue with the installation". The presence of new distributions doesn't invalidate the hashes that are already in the lock file, and pipenv will work just fine if you only supply it wheel hashes and not an sdist hash, which means that this case isn't one of "there are additional hashes so we must error" and moreso unique to "there is now a wheel and our preference for wheel overrides our preference for installing from hash-validated installation candidates."

[n1ngu]

@0xdade yeah I hadn't thought in the impact on bisecting. Quite an issue!

I still think there is an easy path to maintain reproducibility once a package causing this issue is identified. Playing with pip's no-binary option like

export PIP_NO_BINARY=python-crontab
pipenv install --deploy

should do the trick.

[matteius]

I would just update the lock file (relock) to include the new hash, as this is an edge case of generating a lock file while another package is in the process of publishing it. Its not so possible to add a validation check to pipenv as its pip that is preferring the wheel file and failing the hash check. Perhaps you would like pip to prefer to install one of the hashes provided if available, but that would be a feature request to pip.

[0xdade]

@matteius unfortunately just regenerating the lock doesn't really help for working on older versions of a repo, but I did dig into the pipenv code and realized it might be a pip problem rather than pipenv. I suppose one potential way to address it in old builds might be to ignore hashes for that package, if that's possible. Would still require a modification to the build for any older versions, but that's not too bad.

Thanks for pointing towards pip, I may look into that to see if implementing a hash-preference over wheel-preference flag might be feasible.

Hope you have good holidays!

[n1ngu]

So, should this issue be transferred to pypa/pip? I am not allowed to that myself, am I?

[matteius]

You would have to open a new issue with pip and reference back to this one -- we do not have permission to transfer the issues over there.

[n1ngu]

Follow-up in pypa/pip#11692

It turns out pip==22.2.2 was not affected by this so pipenv releases vendoring former pip versions may be also free from this issue.

If you agree, I'll leave this issue open as a tracker that the vendored pip should be bumped to whatever future version fixes this (as I understand a downgrade is out of the table).