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

"pip install --quiet" hides conflict information #10519

Open
1 task done
mitchhentges opened this issue Sep 28, 2021 · 4 comments
Open
1 task done

"pip install --quiet" hides conflict information #10519

mitchhentges opened this issue Sep 28, 2021 · 4 comments
Labels
C: error messages Improving error messages C: logging Information Logging type: bug A confirmed bug or unintended behavior

Comments

@mitchhentges
Copy link

Description

When using --quiet to hide some pip output, it no longer elaborates on which specific packages are conflicting:

$ pip install --constraint constraint.txt click==7.1.2 --quiet
ERROR: Cannot install click==7.1.2 because these package versions have conflicting dependencies.
ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/user_guide/#fixing-conflicting-dependencies
$ pip install --constraint constraint.txt click==7.1.2
ERROR: Cannot install click==7.1.2 because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested click==7.1.2
    The user requested (constraint) click==7.0

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict

ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/user_guide/#fixing-conflicting-dependencies

Expected behavior

I'd expect output that looks something like this:

$ pip install --constraint constraint.txt click==7.1.2 --quiet
ERROR: Cannot install click==7.1.2 because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested click==7.1.2
    The user requested (constraint) click==7.0

ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/user_guide/#fixing-conflicting-dependencies

pip version

21.2.3

Python version

3.6

OS

Fedora 34

How to Reproduce

$ echo "click==7.0" > constraint.txt
$ pip install --constraint constraint.txt click==7.1.2 --quiet

Output

No response

Code of Conduct

@mitchhentges mitchhentges added S: needs triage Issues/PRs that need to be triaged type: bug A confirmed bug or unintended behavior labels Sep 28, 2021
@DiddiLeija
Copy link
Member

DiddiLeija commented Sep 29, 2021

I consider this is a feature request to the error messages.

@DiddiLeija DiddiLeija added C: error messages Improving error messages type: feature request Request for a new feature and removed type: bug A confirmed bug or unintended behavior S: needs triage Issues/PRs that need to be triaged labels Sep 29, 2021
@pradyunsg pradyunsg added C: logging Information Logging type: bug A confirmed bug or unintended behavior and removed type: feature request Request for a new feature labels Sep 29, 2021
@pradyunsg
Copy link
Member

This is probably a "bug" more than a "feature request" -- however, fixing this will be very involved.

The cause for this is very clear: the conflict information is logged at the info level to avoid being presented in red.

That's because we'd gotten fairly clear user feedback that the entire error message being in red was not-great, so we moved away from using logger.critical for it. The fix for this is NOT to use logger.critical but to decouple our output coloring from the level of the output, which... is gonna be a decently involved fix.

@mitchhentges
Copy link
Author

mitchhentges commented Sep 29, 2021

That makes sense, thanks for the background.
Also, unrelated:

  • Thanks pip team for being really responsive on my last couple tickets, I appreciate it and am impressed for the size of this project :)
  • Also, thanks for the great work on pip, I've been migrating some work from the pip~=19.0 era and there's a lot of sweet goodies - I'm really happy with the new resolver especially!

Cheers 🍻

healthy-pod added a commit to healthy-pod/pip that referenced this issue Jan 5, 2022
Previously, each logging level was coupled with a specific
output color. This isn't always ideal because we might need
to log at a certain level but use a custom color (based on
user feedback / see linked issue).

This patch decouples the logs output color from the logging
level.

Fixes pypa#10519
@healthy-pod
Copy link

@pradyunsg @DiddiLeija I opened #10763 to fix this issue and it's ready for review.

healthy-pod added a commit to healthy-pod/pip that referenced this issue Jan 5, 2022
Previously, each logging level was coupled with a specific
output color. This isn't always ideal because we might need
to log at a certain level but use a custom color (based on
user feedback / see linked issue).

This patch decouples the logs output color from the logging
level.

Fixes pypa#10519
healthy-pod added a commit to healthy-pod/pip that referenced this issue Jan 6, 2022
Previously, each logging level was coupled with a specific
output color. This isn't always ideal because we might need
to log at a certain level but use a custom color (based on
user feedback / see linked issue).

This patch decouples the logs output color from the logging
level.

Fixes pypa#10519
healthy-pod added a commit to healthy-pod/pip that referenced this issue Jan 16, 2022
Previously, each logging level was coupled with a specific
output color. This isn't always ideal because we might need
to log at a certain level but use a custom color (based on
user feedback / see linked issue).

This patch decouples the logs output color from the logging
level.

Fixes pypa#10519
healthy-pod added a commit to healthy-pod/pip that referenced this issue Mar 6, 2022
Previously, each logging level was coupled with a specific
output color. This isn't always ideal because we might need
to log at a certain level but use a custom color (based on
user feedback / see linked issue).

This patch decouples the logs output color from the logging
level.

Fixes pypa#10519
healthy-pod added a commit to healthy-pod/pip that referenced this issue May 8, 2022
Previously, each logging level was coupled with a specific
output color. This isn't always ideal because we might need
to log at a certain level but use a custom color (based on
user feedback / see linked issue).

This patch decouples the logs output color from the logging
level.

Fixes pypa#10519
pradyunsg pushed a commit to healthy-pod/pip that referenced this issue Nov 24, 2022
Previously, each logging level was coupled with a specific
output color. This isn't always ideal because we might need
to log at a certain level but use a custom color (based on
user feedback / see linked issue).

This patch decouples the logs output color from the logging
level.

Fixes pypa#10519
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: error messages Improving error messages C: logging Information Logging type: bug A confirmed bug or unintended behavior
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants