We didn’t give enough info, sorry.  This bug is not reproducible with packaging, it only shows when using the distutils2 repository with Python 2.5, 2.6 or 3.1.  I think it’s related to the absence of built-in handler of last resort.

(packaging’s logger is named “packaging” and d2’s is “distutils2”, that’s why your grep did not find it.  This is one of the few differences between both codebases that I will fix before the betas.)

> Looking at packaging.run.main() - it calls Dispatcher(args), and any exception in Dispatcher.__init__()
> before the call to _set_logger could lead to a logging call being made before a handler is set up.
> Suggestion: set the handler as early as possible, perhaps in main() where the other handlers logic is, and
> just set the level later (as that is the only thing that depends on verbosity settings passed in via
> command line flags).
Thanks, I will try that!

> 1. Why are the packaging logger's handlers are saved and restored en masse - all that is happening is that
> a handler is being added in Dispatcher._set_logger, so it would seem to be enough to call removeHandler().
Tarek added that in d53e813ffe58 to fix regrtest warnings about test_packaging modifying logging._handlers.

> 2. There should normally be no need to set both the logger's *and* and handler's level to the same value -
> if the event fails the logger's level test, it will not be passed to handlers anyway. In packaging code I
> found no reference to any other loggers than "packaging" - i.e. no child loggers whose events might need to
> be blocked at the handler level.
Yes, the whole package only uses one logger, and we don’t want to stop messages: the application (pysetup, pip, etc.) must be able to set the level.  I’ll remove the code that sets a level on the logger and write a test to make sure that a client can get all messages.