Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creating a virtualenv gives no feedback to user #1557

Closed
nsoranzo opened this issue Feb 10, 2020 · 11 comments · Fixed by #1569
Closed

Creating a virtualenv gives no feedback to user #1557

nsoranzo opened this issue Feb 10, 2020 · 11 comments · Fixed by #1569

Comments

@nsoranzo
Copy link

@nsoranzo nsoranzo commented Feb 10, 2020

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

This comment has been minimized.

Copy link
Contributor

@gaborbernat gaborbernat commented Feb 10, 2020

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

This comment has been minimized.

Copy link
Author

@nsoranzo nsoranzo commented Feb 11, 2020

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

This comment has been minimized.

Copy link
Member

@pfmoore pfmoore commented Feb 11, 2020

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

This comment has been minimized.

Copy link
Contributor

@gaborbernat gaborbernat commented Feb 11, 2020

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

This comment has been minimized.

Copy link
Member

@pfmoore pfmoore commented Feb 11, 2020

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

@gaborbernat

This comment has been minimized.

Copy link
Contributor

@gaborbernat gaborbernat commented Feb 11, 2020

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

@pradyunsg

This comment has been minimized.

Copy link
Member

@pradyunsg pradyunsg commented Feb 11, 2020

On board for making dest required.

@nsoranzo

This comment has been minimized.

Copy link
Author

@nsoranzo nsoranzo commented Feb 11, 2020

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

@pradyunsg

This comment has been minimized.

Copy link
Member

@pradyunsg pradyunsg commented Feb 11, 2020

@nzoranzo we fixed both. :)

@nsoranzo

This comment has been minimized.

Copy link
Author

@nsoranzo nsoranzo commented Feb 11, 2020

Perfect, thanks!

@gaborbernat

This comment has been minimized.

Copy link
Contributor

@gaborbernat gaborbernat commented Feb 11, 2020

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.

thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

4 participants
You can’t perform that action at this time.