You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to produce really deterministic builds / reproducible environments, pipenv needs to delete packages that were uninstalled in other environments of the same project. But even if pipenv uninstall correctly updates the Pipfile.lock, pipenv sync (in another environment) fails to uninstall the package.
This seems like a serious concern to me, as it can hide huge differences between environments. This brings problems when one creates a new, tabula rasa environment and something that worked breaks, because it depends on a package that was absent from the lockfile.
Expected result
pipenv uninstalls from the environment the packages not present in the Pipfile.lock.
Actual result
pipenv keeps the "dirty" package, possibly contaminating builds.
Steps to replicate
Easiest way to replicate is to install a package through pip (which does not change Pipfile.lock) and then doing a pipenv sync. This simulates the situation of a shared lockfile that gets changed in one environment (deleting a package) with pipfile ignoring the change.
This is intended because the community used to pip is not comfortable with auto-removal. Use pipenv clean to remove unspecified packages instead. Documentation pull request regarding this behaviour is welcomed.
I also expected pipenv sync to, well, synchronize the environment to Pipenv.lock.
Now trying Laski's repro steps but pipenv clean still doesn't remove Unidecode.
I'm on Windows 10, Python 2.7.15 x64, Pipenv 2018.10.13.
Edit: Sorry, just found #3104 and will wait for the next release.
This is intended because the community used to pip is not comfortable with auto-removal. Use pipenv clean to remove unspecified packages instead. Documentation pull request regarding this behaviour is welcomed.
@uranusjr are we really certain about this assumption? Some users may come from JavaScript, where npm ci behaves differently. Besides, if people wanted to use pip and be happy about it, they probably wouldn't switch to Pipenv. Maybe it's worth exploring this idea after all?
Issue description
In order to produce really deterministic builds / reproducible environments, pipenv needs to delete packages that were
uninstall
ed in other environments of the same project. But even ifpipenv uninstall
correctly updates thePipfile.lock
,pipenv sync
(in another environment) fails to uninstall the package.This seems like a serious concern to me, as it can hide huge differences between environments. This brings problems when one creates a new, tabula rasa environment and something that worked breaks, because it depends on a package that was absent from the lockfile.
Expected result
pipenv uninstalls from the environment the packages not present in the
Pipfile.lock
.Actual result
pipenv keeps the "dirty" package, possibly contaminating builds.
Steps to replicate
Easiest way to replicate is to install a package through
pip
(which does not changePipfile.lock
) and then doing apipenv sync
. This simulates the situation of a shared lockfile that gets changed in one environment (deleting a package) with pipfile ignoring the change.On an empty directory, run
cat Pipfile.lock
outputs:but
pip freeze
outputs:instead of the expected
The text was updated successfully, but these errors were encountered: