Skip to content

Suppress "deactivate/activate foo" message #168

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

Closed
puhitaku opened this issue Apr 3, 2016 · 5 comments
Closed

Suppress "deactivate/activate foo" message #168

puhitaku opened this issue Apr 3, 2016 · 5 comments

Comments

@puhitaku
Copy link
Contributor

puhitaku commented Apr 3, 2016

I recently installed pyenv-virtualenv and found that entering a directory which I set a local env with pyenv local foo makes "deactivate / activate foo" message.

I'm used to old behavior - pyenv says nothing without setting VERBOSE - so I feel it's terribly annoying.

I read related Issue #104 #110 and your commit bf7e9ba .
AFAIK prompt changing functionality was restored and can be disabled with setting PYENV_VIRTUALENV_DISABLE_PROMPT but activate messages are not. In my opinion providing user a way to disable the message should be provided.

Please give me your opinion and if you like it I'll send you a PR. Thanks.

@yyuu
Copy link
Collaborator

yyuu commented Apr 3, 2016

Adding something like PYENV_VIRTUALENV_VERBOSE_ACTIVATE would be better.

@yyuu
Copy link
Collaborator

yyuu commented Apr 3, 2016

Or, use -v argument given to pyenv-virtualenv-init? Both should work at least. From consistency point of view, the former might be better.

@puhitaku
Copy link
Contributor Author

puhitaku commented Apr 4, 2016

PYENV_VIRTUALENV_VERBOSE_ACTIVATE sounds better. But it sounds like not showing activating messages will be the default behavior, while pyenv shows the messages by default recently.

I like quiet pyenv but am worrying about changing default behavior. I want to respect @yyuu 's opinion.

@yyuu
Copy link
Collaborator

yyuu commented Apr 4, 2016

IIRC, the verbosity in messaging didn't change recently. Or, I didn't intend to change the behaviour at that time, at least.

Basically I agree with you; show messages only if there's something wrong should be the default behaviour. Kind of "incompatibility" in behaviour is always a matter and what we should avoid. Although some "changes" in messaging must be allowed. I believe that "quiet by default" principle could be the way for every Unix tools.

@yyuu
Copy link
Collaborator

yyuu commented May 20, 2016

I believe this has been fixed by #169 and #171. Please let me know if there's something remaining.

@yyuu yyuu closed this as completed May 20, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants