--pypi-mirror not applied during virtualenv creation

[JacobHenner]

When starting a new project using pipenv with --pypi-mirror specified, virtualenv uses pip without respecting the --pypi-mirror setting.

If PyPI is inaccessible during this process, virtualenv falls back to using local copies of necessary packages and pipenv silently proceeds. However, if connections to PyPI time out (e.g. if packets are dropped instead of rejected by a firewall), pip (and virtualenv) will hang, and pipenv will timeout.

[JacobHenner]

I've started working on the fix for this and hope to have it available for review by tomorrow. I intend to set the PIP_INDEX_URL environment variable to the value of --pypi-mirror when calling virtualenv in do_create_virtualenv.

This was not detected during prior testing, as pip/virtualenv will silently fail if connections to pypi fail. However, pip will hang (which will cause pipenv to time out) if connections to pypi hang.

[techalchemy]

Thanks for digging into this. Do you want to tackle it? Is it a good idea to handle the exception(s)? -- are there any?

If not, should we temporarily set the default pip index while we create the environment?

(I see after typing this that you like the second option, which sounds fine to me)

[JacobHenner]

Yeah, I'll tackle it. I see two options:

1. If --pypi-mirror is set, pass --no-download to virtualenv.
2. If it's set, temporarily set the default pip index via environment variable before calling virtualenv. There's no need to refine this behavior further, as all of the packages pip will try to download will necessarily be PyPI packages.

I think 2 is probably more consistent with what the user would expect.

[techalchemy]

I'm marking our (immediate) bugfix release as 7.0, but really we are gonna get it released whenever we can.

If this is done whenever that is done, we will include it in the bugfix release. If not, no pressure, we can get this in on the next cycle