distutils config files deprecation too noisy, too early, wrong audience

Description

When I install packages outside a virtualenv using Homebrew, I get multiple deprecation warnings per run; these warnings are not intended for me, seem unlikely to affect me for two years, and there is no way to silence them.

There is no rate-limit on this warning. There is no pip --use-deprecated option to quiet this warning. python3 -W ignore::DeprecationWarning -m pip doesn’t work (and arguably shouldn’t); -W ignore::Warning does work, but I assume there are other warnings I do want to see.

~ dilemma$ python3 -m pip install rich
DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
Collecting rich
  Using cached rich-10.15.2-py3-none-any.whl (214 kB)
Collecting pygments<3.0.0,>=2.6.0
  Using cached Pygments-2.10.0-py3-none-any.whl (1.0 MB)
Collecting commonmark<0.10.0,>=0.9.0
  Using cached commonmark-0.9.1-py2.py3-none-any.whl (51 kB)
Collecting colorama<0.5.0,>=0.4.0
  Using cached colorama-0.4.4-py2.py3-none-any.whl (16 kB)
Installing collected packages: pygments, commonmark, colorama, rich
  DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
  DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
  DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
  DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
Successfully installed colorama-0.4.4 commonmark-0.9.1 pygments-2.10.0 rich-10.15.2
~ dilemma$ 

Note that the simplest way of triggering this is just running pip install by itself:

~ dilemma$ python3 -m pip install
DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
ERROR: You must give at least one requirement to install (see "pip help install")
~ dilemma$

Expected behavior

1. I am a relatively sophisticated user. If my distro is doing something bad, maybe I want to hear about it. But I also want to hear about the timeframe it is likely to affect me. If we’re talking about Python 3.12, I don’t have to care for two years.

2. Many inexperienced users will become alarmed at these deprecation warnings, especially because they are printed so often.

My expectation is that this will be printed at most once per pip version upgrade:

DEPRECATION WARNING: Your environment configures installation schemes
using distutils config files. This behavior is deprecated, and `pip`
will stop working in your environment with the release of Foobar 4.23
(expected October 2023). If you are a Homebrew or Linuxbrew Python
user, please see further details at
https://github.com/Homebrew/homebrew-core/issues/76621

pip version

pip 21.3.1

Python version

Python 3.9.9 (Homebrew 3.3.6-72-g5096d6e; https://github.com/Homebrew/homebrew-core/blob/cb104b31ef5762265f3bf253493df23d1a533171/Formula/python%403.9.rb)

OS

macOS 11.6.1

How to Reproduce

1. Install Homebrew 3.3.6, install python
2. python3 -m pip install
3. Note the warning intended for Homebrew maintainers
4. python3 -m pip install
5. Note the warning apparently not relevant to you for at least a year
6. python3 -m pip install
7. Note the warning you can’t do anything about
8. python3 -m pip install
9. Note the warning for the fourth time in a single session

Output

DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
ERROR: You must give at least one requirement to install (see "pip help install")

DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
ERROR: You must give at least one requirement to install (see "pip help install")

DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
ERROR: You must give at least one requirement to install (see "pip help install")

DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
ERROR: You must give at least one requirement to install (see "pip help install")

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[potiuk]

Here is another example of similar behaviour, with an extensive discussion https://github.com/pypa/pip/issues/10556 and attempt to improve the message to be more factual and helpful : https://github.com/pypa/pip/pull/10772

I think this should signal to PIP maintainers that maybe they should rethink the way they are communicating with their users.

I believe that warnings should be:

• actionable - they should provide the users with an action they can do to remove the warning (many of PIP warnings actually are, so this is not a “general” problem

• factual - they recommendations/proposals that are included in the warning shoudl not be misleading for various kind of users (especially if there are significant groups of users who are mislead). Again there are a number of warnings that are factual. Not all though.

• helpful - rather than intimidate the users (and essentially tell them 'you are wrong - go figure why`, they should be kind and helpful. Users - especially when things change, should be gently guided into improving their behaviour rather than shouted at for doing it wrong. Many of the warnings or PIP actually are and were helpful already. But some are not.

• provide context - when the explanation of the warning cannot be put in one/few lines, they should provide a helpful link where context and more elaborated discussion why the warning is important is explained. Here I think the problem is that a lot of the context is in discussions - mostly around PEPs, which many (vast majority actually) of PIP users have no idea about or no capacity and time to read and understand the context. Some short summary and link to such context could be very helpful for a number of warnings.

• silenceable - when there is a case where warning might be “false negative” - there should be a way to disable the warning - this is especially important for “power users” who might be able to asses the situation and decide on their own if the warning is applicable. Some warnings are silenceable but some of those that might provide false-negatives are not. I think it woudl be great if PIP maintainers listen to the users and whenever there is a significant group of cases and users where the warning is not applicable, they should add an option to silence those warnings.

In my opinion if warnings do not follow those principles (and this is just learning from developing Airflow and listening to thousands of users) the warnings will be simply treated as “noise” - wery similar to spam received. This makes them useless and rather tnan encourage them to a good behaviour, they make the users develop blind-spot and the users tend to ignore the warnings (even the important ones).

I do not tell (and this is not my intention) to say “PIP is doing it wrong”. Not at all. There are many cases where the warnings are good. But also I think PIP maintainers should be open to improve some of the warnings following those principles. I have a feeling that in many cases (certainly that was the case https://github.com/pypa/pip/issues/10556) rational arguments loose a bit with some ‘doctrinal’ thinking and lack of being open and understanding that there are different kinds of users and use cases.

Maybe that’s deliberate and all PIP maintainers agree to that approach. Maybe that’s just some people having extremely strong opinions and others not willing to get into opposing them. I have no idea, but the discussion there seems to ignore rational arguments.

Kind request to PIP maintainers to consider that opinion and rethink the approach.

[jorhett]

FWIW, I just installed 21.3 and then installed something fairly basic/essential and got >60 lines of this message. This is beyond useless to a user, and not even actionable for me while developing python programs.

Minimizing the output would be nice, but it would appear on the surface that you’re telling the wrong audience. No user controls how a package is built. Why not output these during the package build, not the package installation?