Creating a virtualenv gives no feedback to user

[nsoranzo]

Behaviour pre v20:

(virtualenv16.7.9_venv) $ virtualenv --version
16.7.9
(virtualenv16.7.9_venv) $ virtualenv test_venv
Using real prefix '/usr'
New python executable in /tmp/test_venv/bin/python2
Also creating executable in /tmp/test_venv/bin/python
Installing setuptools, pip, wheel...
done.

New behaviour in v20.0.1:

(virtualenv20.0.1_venv) $ virtualenv --version
virtualenv 20.0.1 from /tmp/virtualenv20.0.1_venv/local/lib/python2.7/site-packages/virtualenv/__init__.pyc
(virtualenv20.0.1_venv) $ virtualenv test_venv

It doesn't need to print the same messages of course, but at least something!

It is especially surprising in the case of running just virtualenv, which before was printing the help and returning an error code because of the missing DEST_DIR, while now creates a virtualenv in the new default venv and returns 0 without any feedback.

[gaborbernat]

Has been commented during the beta that some people like the silent out of box behaviour, similarly how the rm command does not print just does. If you pass in a -v you'll get more feedback. I'm split between the current behaviour and maybe a one line final report 🤔on success. If you'd have warning/errors during the creation those you would already see.

[nsoranzo]

The behaviour of "silent" shell commands is counter-intuitive and needs to be explained to new users, in my experience as Software Carpentry instructor. In virtualenv case, passing from giving feedback to be silent is even more surprising.
I find that git is a great example of how a command-line tool should give feedback, for example git checkout <branch> could be silent but it's not.

[pfmoore]

As someone who said I liked the new quieter behaviour, I will note that I didn't realise that you could omit even the name of the environment (the dest parameter). I'm not keen on this behaviour - I'd prefer dest to be mandatory - but regardless of that I definitely don't like the fact that a bare virtualenv command creates an environment silently.

So, my preference now would be one or both of:

1. Make dest required.
2. Display a single line "Created virtual environment XXX" by default, suppressed with -q.

We could also bikeshed endlessly over the "correct" default for dest_dir (I prefer .venv) 😉

[gaborbernat]

IMHO having it as .venv gives a false impression is a private/hidden, which is not the case (we learned this the hard way in tox). I'd personally would be an advocate of 2, without 1.

[pfmoore]

That's not my ideal, but it works for me. (Arguing over the default name was meant as a joke, by the way).

[gaborbernat]

I'm ok with option 1 too 👍 if both you and @pradyunsg advocate for it 🤷‍♂

[pradyunsg]

On board for making dest required.

[nsoranzo]

If I have to choose, I'd prefer 2), i.e. to have this issue addressed, but preferably both.

[pradyunsg]

@nzoranzo we fixed both. :)

[nsoranzo]

Perfect, thanks!

[gaborbernat]

Hello, a fix for this issue has been released via virtualenv 20.0.2; see https://pypi.org/project/virtualenv/20.0.2/ (https://virtualenv.pypa.io/en/latest/changelog.html#v20-0-2-2020-02-11) . Please give a try and report back if your issue has not been addressed; if not, please comment here, and we'll reopen the ticket. We want to apologize for the inconvenience this has caused you and say thanks for having patience while we resolve the unexpected bugs with this new major release.