_distutils.dist.Distribution.parse_command_line() wrongly causes unexpected change to global state

[vsajip]

This line in the eponymous method:

setuptools/setuptools/_distutils/dist.py

Line 469 in b000f0c

logging.getLogger().setLevel(logging.WARN - 10 * self.verbose)

causes a global change to the root logger. This is unexpected and unwanted when being used as a library. Changes to logging configuration must not in general be made by a library, only by application code. Parsing a command line can be done without running it, and this shouldn't change the root logger.

[abravalheri]

Hi @vsajip, thank you very much for opening the issue.

/cc @jaraco should we transfer this issue to the pypa/distutils repository?

[jaraco]

Perhaps, although setuptools.logging does the same thing:

setuptools/setuptools/logging.py

Line 37 in b000f0c

logging.root.setLevel(level * 10)

So we should probably handle the issue here first.

More importantly, Setuptools and distutils are getting out of the business of acting as a library, except as a backend for builders.

@vsajip - what's your use-case for using Setuptools as a library? Under what conditions does the current implementation cause problems? This behavior goes back decades, so it'll likely be difficult to disentangle, especially with the dual-implementation nature of setuptools+distutils.

[vsajip]

The problem surfaced when I ran the unit tests for an old project (logutils) which uses distutils (it dates from around Python 3.2) - the tests ran fine on Python 3.10, but failed on 3.11 because the legacy code in setup.py called parse_command_line(), and this caused the root logger to have a different initial state than it does under 3.10 and older. (This old project uses python setup.py test to run the tests.)

I would have thought the solution should be to move the logic from parse_command_line() to wherever output is about to be done. I'm not sure whether in this case logging is being used to do normal program output, but if so, then that's not good practice, either. Use of the root logger should only be for simple single-file scripts - in all other cases, named loggers (and not the root) should be used to identify where a logging event is coming from, and to allow application writers or sysadmins to configure logging verbosity for that part of the system.

[owocado]

so this is the culprit, I was scratching my forehead since a month why in my small project the root logger was set to logging.WARN state at startup each time and after doing painstaking debugging every now and then, I just realised today it started occuring ever since I updated setuptools last month from v65.6.0 to latest. It took me a while to find this issue. You guys should revert this change. The amount of debugging I have done to find the cause is insane and this bug is not pleasant to say the least.

This change was introduced in #3674 in case someone find that useful.