Better visibility to deprecations

[jaraco]

Unfortunately, deprecation and removal is the main way I know to inform downstream consumers of breaking changes like these.

Yeah, it's a tough problem. But deprecated or not, I generally assume that core tools work. Version numbers in particular have been historically very lenient, so this is a really fundamental change that caught me off guard.

Build logs are noise, unless there's a problem. So while it's possible that I've seen the xxx is an invalid version and will not be supported in a future release warning flying by in the logs, to me, it isn't a call to action. It's just one line among hundreds.

Suffice to say, if something is going to break, I'd prefer a more detailed message, for example:

******************************************************************************** 
The version number <xxx> on package <yyy> package is no longer valid. 

By January 2023, you need to update version numbers to conform with PEP440 
or your builds may fail. You can retain the old behavior by passing 
the --allow-deprecated-version-numbers option to setup. 

See <some url> for details.
********************************************************************************

I'd also suggest putting the message at the end of the build log, not the beginning. Then it probably would be the first thing that I see after I run a build.

Originally posted by @sethrh in #3772 (comment)

[jaraco]

I agree the messaging could be better. Other ways we may be able to improve the visibility of warnings:

• Setuptools could use color to highlight warnings (similar to pip).
• Document a recommendation that users run with (setuptools/pkg_resources) deprecation warnings set to error in CI systems.
• Propagate warnings to build frontends and ask those tools to emit warnings more prominently.

[pradyunsg]

• Propagate warnings to build frontends and ask those tools to emit warnings more prominently.

x-ref pypa/pyproject-hooks#157

[sinoroc]

What if setuptools were to output warnings and errors only by default, and output nothing if all is well? The current output is quite verbose.

As far as I know python -m build does not have any --verbose or --quiet flags.

In the case of setuptools, one can run python setup.py sdist --verbose if needed. I am not sure about other build back-ends.

Maybe what is needed is an agreement on some environment variable names so that one can run something like the following needed:

BUILD_BACK_END_VERBOSITY=3 python -m build

Apologies if I am stating the obvious or things that have been mentioned already.

[abravalheri]

As far as I know python -m build does not have any --verbose or --quiet flags

Hi @sinoroc , if you are using build, you can use -C--verbose and -C--quiet to control setuptools output. These are backend-specific (that is why you need the -C prefix) and will work with recent versions of setuptools.

[sinoroc]

Ah, thanks @abravalheri

To me this means that it would be "safe" for setuptools to hide all its output by default, keep only the warnings and errors. Maybe this could be a good first step to help the deprecation warnings pop out more. And whoever needs verbose output can run python -m build -C--verbose.

[abravalheri]

If I am remembering it correctly that is not exactly how those flags work 😅 (you can double check that with python setup.py).

The default output has "medium" verbosity. If you add verbose it gets even more verbose. If you add quiet, then it will only display the warnings.

[sinoroc]

Right. My suggestion here is to change the default to be less verbose. If all goes well output nothing (or maybe just a confirmation that "[file name]" was created).