--download option is problematic as a default

[grothesque]

I understand why the option --download has been switched on by default but I suggest to reconsider this because it mixes local and online sources of code in a confusing and potentially error-prone way.

Virtualenv is a command line tool that has no obvious relation to the internet. Still, running virtualenv foo will produce different results based on whether an internet connection is available or not. This alone, IMHO, is enough to disqualify the current default behavior.

The current behavior means that when I develop a package in a virtualenv that was created a week ago, and create a fresh virtualenv later on exactly the same unchanged system, I might not get an equivalent environment. In fact, there is no obvious way to recreate the environment from one week ago. My package (that uses setuptools in its setup.py), might be affected by a change of the environment in subtle ways.

Here is a Debian bug report (by a different author) that lists problems with the current default from a different point of view.

If the versions of setuptools or pip in an virtualenv are too old to pip install some package, I suggest that an error message is presented to the user that tells how to upgrade these packages manually. This functionality is needed even with the current behavior, because a user might be using an outdated virtualenv to install a package that requires a newer setuptools, say.

[gaborbernat]

Although, --download is the default if you don't want network usage you can always pass the --no-download. I can see valid points for both sides, both with some advantages and some disadvantages. In such cases, unless more people come ahead prooving that --donwload is horrible I'm inclined to keep the status quo.

This default behavior is a bad idea, to begin with...
there's no guarantee that the code downloaded is free software

Yes, it is, we only pull packages that are free, pip, wheel and setuptools.

there's no guarantee that the code downloaded won't change its behavior from one day to the next

This is true, but all those three packages maintain backwards compatibility historically, and there's no intention to change that as far as public API goes. Furthermore, this can also work in your advantage, as a potential security flaw/bug discovered in any of those packages after virtualenv release gets pulled in at creation time.

there isn't even any authentication of the code's authorship, beyond verifying the TLS certificate of 'pypi.python.org', which of course are also problems with many typical uses of pip, but in that case the user is at least arguably making a deliberate choice.

AFAIK, pip does have a vendored certificate validation, that can be overwritten with an OS packaged certificate.

[gaborbernat]

Closing this as per above, for now.