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

Add install option to hide "Requirement already satisfied" log info. #5900

Open
mlorant opened this issue Oct 18, 2018 · 12 comments
Open

Add install option to hide "Requirement already satisfied" log info. #5900

mlorant opened this issue Oct 18, 2018 · 12 comments
Labels
C: logging Information Logging type: feature request Request for a new feature

Comments

@mlorant
Copy link

mlorant commented Oct 18, 2018

What's the problem this feature will solve?
I'm running pip install -r requirements.txt at each deployment to keep my third-parties up to date with the code. With several dozens of requirements, the log is pretty big, while I don't really care to know that 99 % of the libs was "already satisfied" from one deployment to the next one. The worst is sub-dependencies are also shown, so in fact I can get up to 200 lines displayed...

Most of the execution trace is:

Requirement already satisfied: setuptools==36.6.0 in my_venv/lib/python3.5/site-packages (from -r requirements.txt (line 8)) (36.6.0)
Requirement already satisfied: Django==2.1.2 in my_venv/lib/python3.5/site-packages (from -r requirements.txt (line 9)) (2.1.2)
Requirement already satisfied: django-formtools==2.1 in my_venv/lib/python3.5/site-packages (from -r requirements.txt (line 10)) (2.1)
Requirement already satisfied: djangorestframework==3.7.7 in my_venv/lib/python3.5/site-packages (from -r requirements.txt (line 11)) (3.7.7)
Requirement already satisfied: django-rest-framework-mongoengine==3.3.0 in my_venv/lib/python3.5/site-packages (from -r requirements.txt (line 12)) (3.3.0)
[...]
Requirement already satisfied: pycparser in my_venv/lib/python3.5/site-packages (from cffi>=1.4.1->cryptography>=1.1->fabric==2.3.1->-r requirements.txt (line 93)) (2.14)

Describe the solution you'd like
I would like to be able to hide those warnings with a simple command argument. For example:

pip install -r requirements.txt --no-warn-already-satisfied

Alternative Solutions
It seems that -q is doing the job, but it is hiding in fact all log message at INFO level, so new installations get hidden too... I still want to monitor that so I can log any environment changes from my deployment log.
For now, the only viable solution is to use standard UNIX tools, and exclude those lines with grep: https://stackoverflow.com/questions/36350951/hide-requirement-already-satisfied-warning It does work, but it could be better :)

Additional context
The name --no-warn-already-satisfied would be consistent with other options that already exists in pip install arguments, such as no-warn-conflicts and no-warn-script-location

@cjerdonek cjerdonek added type: enhancement Improvements to functionality C: logging Information Logging labels Oct 20, 2018
@uranusjr
Copy link
Member

Regarding consistency, the problem with no-warn-already-satisfied is that those already-satisfied messages are not warnings (both examples you gave are).

@cjerdonek
Copy link
Member

It seems like a more scalable approach would be for pip to let one pass one or more "ids" of messages to suppress (like how Django, flake, etc. operate).

Then there wouldn't need to be a separate flag for each message (of which there can be very many). Also, allowing message ids would make it easier to support suppressing many different messages without having to open a separate PR for each one.

@pradyunsg
Copy link
Member

I like @cjerdonek's suggestion here.

It's definitely more scalable and makes more sense to allow.

@mlorant
Copy link
Author

mlorant commented Oct 28, 2018

I like the proposed approach too. I did not look into pip before, but indeed the "already met" messages are coming from a log.info statement, so a "--no-warn" flag would not be consistent.

The idea of having a keyword-code for each type of output and being able to disable one or many in a single command line argument seems to resolve most of the use cases I guess, and we could even suppress the no-warn-conflicts and no-warn-script-location arguments in the long term.

@leonmax
Copy link

leonmax commented Oct 30, 2018

a temporary solution could be:

pip install -r requirements.txt | grep -v 'already satisfied'

works really well for me

@chuckfossen
Copy link

My pip install -r requirements.txt command is in a Makefile but is followed by && so the "| grep -v already" breaks the &&.
pip install -r requirements.txt && another_command
It would be nice to have an option to quiet these messages.

@LeoDashTM
Copy link

My pip install -r requirements.txt command is in a Makefile but is followed by && so the "| grep -v already" breaks the &&.
pip install -r requirements.txt && another_command
It would be nice to have an option to quiet these messages.

I think you could do pip install -r requirements.txt | grep -v 'already satisfied' || true
The negative effect of such an approach seems to be the fact that if the "pip install" fails, then the whole statement does not error out and the entire script continues...

@cjerdonek cjerdonek removed the state: needs discussion This needs some more discussion label May 7, 2019
@cjerdonek
Copy link
Member

I removed the "discussion needed" label as I think we agree the right way to fix this is to address: #6119

Rather than closing as a duplicate, I'll leave this open for easier discoverability and since there's not much harm.

@LeoDashTM
Copy link

My pip install -r requirements.txt command is in a Makefile but is followed by && so the "| grep -v already" breaks the &&.
pip install -r requirements.txt && another_command
It would be nice to have an option to quiet these messages.

I think you could do pip install -r requirements.txt | grep -v 'already satisfied' || true
The negative effect of such an approach seems to be the fact that if the "pip install" fails, then the whole statement does not error out and the entire script continues...

The solution to the above seems to be the following:
set -o pipefail; pip install -r requirements.txt | { grep -v "already satisfied" || :; }
which errors out if pip install errors out, but does not error out if grep errors out i.e. does not output anything, and grep filters out unneeded output.

timothymiller added a commit to timothymiller/cloudflare-ddns that referenced this issue Oct 30, 2021
@flaviu-gostin
Copy link

This option would also be useful in Jupyter notebooks to prevent cluttering output cells when running something like %pip install tensorflow --user --upgrade. Tensorflow has a lot of requirements, so there is a long list of "Requirement already satisfied ..." items.

@wirekang
Copy link

wirekang commented Apr 7, 2023

These messages are so annoying and cause unnecessary resource usage.

@lyderichti59
Copy link

lyderichti59 commented Jun 27, 2023

The solution to the above seems to be the following:
set -o pipefail; pip install -r requirements.txt | { grep -v "already satisfied" || :; }
which errors out if pip install errors out, but does not error out if grep errors out i.e. does not output anything, and grep
filters out unneeded output.

You can also get the 'pip ...' part's exit status in bash thanks to the PIPESTATUS array, but it's not POSIX.
It led me to the following oneliner, using bash to be explicit about non POSIXness

bash -c '(pip install -r requirements.txt | grep -v "already satisfied"; exit ${PIPESTATUS[0]})'

It avoids having to change the pipefail option; Obviously, I'm in favour of a feature flag such as the one OP suggested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: logging Information Logging type: feature request Request for a new feature
Projects
None yet
Development

No branches or pull requests

10 participants