Re-apply Pipenv --system bug workaround
#2011
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In #2000, Pipenv was updated to v2026.0.3, which contained a number of fixes for the historically very buggy `--system` mode. Since that Pipenv release was meant to fix many of the `--system` bugs, one of the workarounds for those bugs was removed, since even without it the existing tests for that bug still passed (implying the upstream fixes had worked as expected). However, it appears that the bug still exists in some form that was not being picked up by the original testcase, as reported in: #2000 (comment) As such, I've had to re-add the workaround. This also affects the logs, since in the new Pipenv version, if `PIPENV_VERBOSITY="-1"` is set (which is required to stop an obnoxious multi-line warning about a venv being present), then the `Installing dependencies from ...` line is no longer printed. It seems the bug now only reproduces with different versions of the `certifi` package, so I've updated the test fixture accordingly. (My first thought was that perhaps the difference is whether our testcase's `certifi` matches the Pipenv vendored version exactly or not, however, varying to another older version also didn't reproduce?). I've also added `packaging` as another testcase dependency, in the hope that in the future at least one of these packages will be able to reproduce the issue, should we try and remove the workaround again. Longer term, these continual Pipenv bugs are making me inclined to deprecate/strongly discourage Pipenv usage, given there are now much more reliable/better maintained/faster alternatives (such as uv) that don't suffer from these chronic bugs. GUS-W-20819376.
edmorley
force-pushed
the
pipenv-system-workaround
branch
from
d143d10 to
4f102f8
Compare
Malax
approved these changes
Jan 8, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In #2000, Pipenv was updated to v2026.0.3, which contained a number of fixes for the historically very buggy
--systemmode.Since that Pipenv release was meant to fix many of the
--systembugs, one of the workarounds for those bugs was removed, since even without the workaround the regression test for that bug still passed (implying the upstream fixes had worked as expected).However, it appears that the bug still exists in some form that was not being picked up by the original testcase, as reported in:
#2000 (comment)
As such, I've had to re-add the workaround. This also affects the logs, since in the new Pipenv version, if
PIPENV_VERBOSITY="-1"is set (which is required to stop an annoying multi-line warning about a venv being present), then theInstalling dependencies from ...line is no longer printed.It seems the bug now only reproduces with different versions of the
certifipackage, so I've updated the test fixture accordingly. (My first thought was that perhaps the difference is whether our testcase'scertifimatches the Pipenv vendored version exactly or not, however, varying to another older version also didn't reproduce?).I've also added
packagingas another testcase dependency, in the hope that in the future at least one of these packages will be able to reproduce the issue, should we try and remove the workaround again.Longer term, these continual Pipenv bugs are making me inclined to deprecate/strongly discourage Pipenv usage, given there are now much more reliable/better maintained/faster alternatives (such as uv) that don't suffer from these chronic bugs.
GUS-W-20819376.