This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vinay.sajip
Recipients alexis, eric.araujo, tarek, vinay.sajip
Date 2012-03-13.09:11:51
SpamBayes Score 2.0689006e-13
Marked as misclassified No
Message-id <1331629912.85.0.850354907469.issue14273@psf.upfronthosting.co.za>
In-reply-to
Content
I cannot reproduce this, and in fact couldn't find anywhere in packaging in the default branch where a "distutils2" logger is set up. I used grep to look for "getLogger.*(distutils2|__name__)", could some other logic be in use to construct the logger name?

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).

A couple of things I don't quite understand:

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().

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.
History
Date User Action Args
2012-03-13 09:11:52vinay.sajipsetrecipients: + vinay.sajip, tarek, eric.araujo, alexis
2012-03-13 09:11:52vinay.sajipsetmessageid: <1331629912.85.0.850354907469.issue14273@psf.upfronthosting.co.za>
2012-03-13 09:11:52vinay.sajiplinkissue14273 messages
2012-03-13 09:11:51vinay.sajipcreate