When using --use-feature=2020-resolver - Pip fails installing some packages from site-packages in virtualenv

[favipcj]

Hi, I tried looking for a similar issue but I couldn't find anything, although this issue is related with #8731

Environment

pip version: 20.2.4
Python version:3.7
OS: any
Dockerfile that illustrates this issue:

FROM python:3.7
RUN pip install virtualenv requests argparse==1.4.0
RUN /usr/local/bin/virtualenv --system-site-packages tst
RUN /tst/bin/pip3.7 install --upgrade pip==20.2.4 && /tst/bin/pip3.7 install  --use-feature=2020-resolver --proxy 127.0.0.1 --retries 0 --timeout 1 argparse==1.4.0

Description
When trying to install some packages like argparse the installation is failing if there is no connection to a remote repo that contains that package.

Using the same example from #8731, the issue seems to be happening only with some packages like argparse and not with requests for example.

Expected behavior
Pip installs argparse correctly in the virtualenv in the above example.

Output

ERROR: Could not find a version that satisfies the requirement argparse==1.4.0
ERROR: No matching distribution found for argparse==1.4.0

[uranusjr]

We’re ignoring three packages, argparse, wsgiref, and python, because they have the same names with stdlib modules and cause problems if you try to upgrading them. It should be possible to fix this, but… why do you want to install them in the first place?

[favipcj]

For getting all the libraries versions pinned in our libraries we compile our requirements using pip-tools, so argparse get's added as part of those requirements.
The issue that we are seeing is that when we have a library A with that requirement(argparse) a library B that depends from A, cannot get installed because argparse is not able to be installed for the error described before.

For example using the library dateutils you get argparse as part of your requirements

[pfmoore]

dateutils should really only depend on argparse for very old Python versions, so the bug is probably with them.

[uranusjr]

I opened jmcantrell/python-dateutils#10 for this.

[pradyunsg]

@pfmoore @uranusjr I think it's OK to call this a downstream issue. If you think so too, I think @uranusjr's PR covers this TBH.

[favipcj]

thanks guys, just to clarify; this scenario can happen only with libraries that have argparse or wsgiref as dependency in their requirements right ?

[uranusjr]

@favipcj Correct. Technically there’s another package name Python, but that package name is not available on PyPI (I believe it’s squatted by the PSF) and more obviously problematic.

[favipcj]

understood, thanks!

[pradyunsg]

Closing this seems to be resolved. :)