Cannot freeze pip version within the virtualenv

[gsemet]

Hi.

I do not find a way to freeze the pip version installed within the virtualenv (like pipenv install pip==19.3.1). The latest version as of today (20.0.1) has a bug that is cannot install one package (azure-iothub-device-client==1.4.6), while the previous version works.

pipenv seems to force installing to the latest version WITHIN the virtualenv, no matter what we put in the Pipfile. Same I see some of these packages (pip, setuptools) are NOT locked, so when they evolves and introduce a regression, the build fails for no reason.

I strongly recommend to treat these packages like every other ones, ie, allowing user to freeze them to ensure the build is fully reproductible, no matter what happens on pypi.org.

Upstream bug opened: pypa/pip#7644

[ncoghlan]

@techalchemy I'm not sure where this behaviour is coming from, but I can confirm that pip and setuptools don't get included in Pipfile.lock, even if you explicitly add them to Pipfile.

I got bitten by this last week, as I had an old version of pip-tools pinned that wasn't compatible with pip 20.1. That's fixed now (by updating the pip-tools pin to a newer version), but the special casing is definitely unexpected.

[ncoghlan]

While attempting to work around this, I found that pip-tools also refuses to lock pip and setuptools when compiling, emitting this instead:

# The following packages are considered to be unsafe in a requirements file:
# pip
# setuptools

[ncoghlan]

Recategorising as an enhancement request to offer a way for users to decide for themselves which set of risks they want to tolerate (pip-compile stopped pinning pip and setuptools due to problems caused by pinning them, but not pinning them causes a different set of potential problems).

[fridex]

Recategorising as an enhancement request to offer a way for users to decide for themselves which set of risks they want to tolerate (pip-compile stopped pinning pip and setuptools due to problems caused by pinning them, but not pinning them causes a different set of potential problems).

What about pinning them if they are explicitly stated in the Pipfile? Assuming users want to pin them in that case.

[matteius]

@gsemet pipenv vendors in specific version of pip that is part of the project -- so depending on the version of pipenv that you have installed you will have a specific version of pip. setuptools and wheel are its own beasts because pip and requirementslib and maybe other things choose to install the latest versions during resolution and locking cycles and that is very uncontrollable--I've tried recently when setuptools released a new version that broke a test of ours to pin it, but it wasn't really possible and was easier to realize what the actual bug was and fix that to work with the new version of setuptools. I live in fear of new setuptools major version updates after it ruined that weekend of mine.

[matteius]

At this point in time pipenv relies exclusively on its vendor'd pip for internal commands but it still possible to invoke the virtualenv or system pip. The version of the virtualenv pip is revealed by running pipenv run pip freeze --all