Empty arguments not supported w/ python --mvirtualenv /dest/

[benjaoming]

Details

Firstly, I have a patch that's tested and works and will submit a PR soon 😇

In relation a set of specific deployment needs, I found it necessary to try out Read The Docs on a newer platform (Python 3.7), and I think it causes the following breakage:

• Read the Docs project URL: n/a
• Build URL (if applicable): n/a
• Read the Docs username (if applicable): n/a

The issue is also reported 14 days ago here:

https://stackoverflow.com/questions/62050977/readthedocs-virtualenv-error-unrecognized-arguments-during-update-repos

It was also reported in #6915 but closed for the wrong reasons (it's not due to an environment variable or similar)

Reproducing

If there is no option --system-site-packages passed to python3 -mvirtualenv, it will be invoked like this, resulting in an error:

(venv) readthedocs@6d51bf78d765:~/git$ python3.7 -mvirtualenv "" /usr/share/readthedocs/git/user_builds/myproject/envs/latest
usage: virtualenv [--version] [--with-traceback] [-v | -q] [--app-data APP_DATA] [--clear-app-data] [--discovery {builtin}] [-p py] [--creator {builtin,cpython3-posix,venv}] [--seeder {app-data,pip}] [--no-seed]
                  [--activators comma_sep_list] [--clear] [--system-site-packages] [--symlinks | --copies] [--no-download | --download] [--extra-search-dir d [d ...]] [--pip version] [--setuptools version] [--wheel version] [--no-pip]
                  [--no-setuptools] [--no-wheel] [--symlink-app-data] [--prompt prompt] [-h]
                  dest
virtualenv: error: unrecognized arguments: /usr/share/readthedocs/git/user_builds/myproject/envs/latest

Expected Result

I'm pretty sure this is not reproducible for the core team's Docker containers. But you'll probably see it once the Python environments are updated from Python 3.6 to Python 3.7.

Actual Result

My environment fails executing because of an empty-string command line argument.

[stsewd]

I think this is the same as #6893 (comment)

[benjaoming]

Good point, thanks @stsewd, I'll try to address this separately from pinning virtualenv to the same version on both environments, as #6893 (comment) mentions (but sounds like a really good idea, too!)