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

Is there a way to disable / suppress pipenv's "Courtesy Notice" about virtual environments? #2527

Closed
trianta2 opened this issue Jul 5, 2018 · 7 comments · Fixed by #2645
Closed
Labels
Category: Future Issue is planned for the future. good first issue Issues suitable as a newcomer to get familiar with Pipenv! help wanted Type: Enhancement 💡 This is a feature or enhancement request.

Comments

@trianta2
Copy link

trianta2 commented Jul 5, 2018

Each time I invoke pipenv I see:

Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project. You can set PIPENV_IGNORE_VIRTUALENVS=1 to force pipenv to ignore that environment and create its own instead.

Can this be globally suppressed?

@uranusjr
Copy link
Member

uranusjr commented Jul 5, 2018

No, there is not.

@uranusjr uranusjr closed this as completed Jul 5, 2018
@uranusjr
Copy link
Member

uranusjr commented Jul 5, 2018

That said, maybe we can treat an empty PIPENV_IGNORE_VIRTUALENVS as the suppressor.

  • PIPENV_IGNORE_VIRTUALENVS absent—show the message.
  • PIPENV_IGNORE_VIRTUALENVS set to empty string—suppress the message, but use the environment.
  • PIPENV_IGNORE_VIRTUALENVS is not empty—create a nested virtualenv.

@trianta2
Copy link
Author

trianta2 commented Jul 5, 2018

Does PIPENV_IGNORE_VIRTUALENVS=0 have any significance? If pipenv was told to not ignore virtual envs, then that should mean I want to use my existing virtual env, and the courtesy notice should be suppressed.

@techalchemy
Copy link
Member

We have an environment variable to suppress output but we don't use it much. We can add this to the refactor

@techalchemy techalchemy reopened this Jul 5, 2018
@techalchemy techalchemy added Type: Enhancement 💡 This is a feature or enhancement request. help wanted Category: Future Issue is planned for the future. good first issue Issues suitable as a newcomer to get familiar with Pipenv! labels Jul 5, 2018
@max-arnold
Copy link

My current workaround:

pipenv lock --requirements 2> >(grep -v "Courtesy Notice" >&2) > requirements.txt

@uranusjr
Copy link
Member

uranusjr commented Jul 10, 2018

@max-arnold You found a bug! lock -r should output to stdout (it does when you’re not in a virtualenv), but for some reason outputs to stderr when you are inside. You shouldn’t need more than pipenv lock --requirements > requirements.txt. We will fix that. Sorry for the annoyance.


Edit: After some testing, you should be able to run pipenv lock --requirements 2>/dev/null on Linux or Mac. No need for fancy grep-ing.

@max-arnold
Copy link

@uranusjr Fancy grep and redirections are used to filterCourtesy Notice while preserving stderr/stdout separation and exit codes.

Haplo-Dragon added a commit to Haplo-Dragon/pipenv that referenced this issue Jul 13, 2018
Added an environment variable, PIPENV_SUPPRESS_NESTED_WARNING, to be
used to suppress the courtesy notice from warn_in_virtualenv.
Changed wording of the courtesy notice to mention suppression variable.
Fixes pypa#2527.
uranusjr pushed a commit that referenced this issue Jul 25, 2018
Added an environment variable, PIPENV_SUPPRESS_NESTED_WARNING, to be
used to suppress the courtesy notice from warn_in_virtualenv.
Changed wording of the courtesy notice to mention suppression variable.
Fixes #2527.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Future Issue is planned for the future. good first issue Issues suitable as a newcomer to get familiar with Pipenv! help wanted Type: Enhancement 💡 This is a feature or enhancement request.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants