Maybe we could have BaseCommand remove the 'console' handler from the 'django' logger during the command's execution (at least under normal verbosity conditions)?
As mentioned on the pull request, there is also an idea to update management commands to use logging [1]. I think the two ideas could coexist. [1] https://github.com/django/django/pull/3467 On Wednesday, September 16, 2015 at 7:02:57 PM UTC-4, Shai Berger wrote: > > Hi, > > On Wednesday 16 September 2015 03:13:35 Markus Holtermann wrote: > > > > I see the following solutions to bring this PR forward: > > > > 1. Configure `django.db.migrations` logger to not send messages to > > console by default and keep log levels to INFO (for > "Applied/Unapplied > > migration XYZ") and DEBUG (for "Marked migraiton XYZ as > > applied/unapplied") > > 2. Change the log levels for both messages to DEBUG > > 3. Don't propagate messages from `django.db.migrations` logger to > > parents > > 4. Don't go forward with the above mentioned patch amending the > > default log level > > > > I prefer option 1 and clearly document how people can activate the > logger, > > Wait -- so you mean "turn logger off by default"? I'd find that strongly > counter-intuitive. > > > while option 2 is currently implemented but comes with the disadvantage > > that you can't separate the two log levels. > > As I noted on the PR, its biggest disadvantage IMO is that all migration > logging is then done at "DEBUG" level, which undermines the purpose set > forth > in this thread. > > > Option 3 works too, but could cause some weird behavior and confusion if > not > > documented why it's set. > > Yes. Exactly as counter-intuituve as option 1 > > > Option 4, no idea, it sounds correct to me. > > > > I agree that INFO logging should go out to the console when activated by a > management command. > > Let's recap: The main problem is the doubling of messages on migrations, > as > the migrations framework already prints to stdout when it runs migrations. > > A possible solution, then, is to turn off these printings in favor of the > logging. Its big disadvantage, AFAICT, is that the custom printing of > migrations is far prettier than the default logging format. > > Another possible solution is a variation on Option 2 -- change the log > levels > on both messages to DEBUG, but only if settings.DEBUG is on. Where > settings.DEBUG is off, it is also more likely that the django loggers do > not go > to the console. > > Yet another solution is to make a finer definition of which loggers print > to > console by default -- for example, define a "django2"[1] logger hierarchy, > with > the migrations logger under it instead of under "django", where django2 > does > not propagate to root and, by default, has no handlers. > > Out of ideas, > Shai. > > [1] Yes, I know. Not a very descriptive name. It's 2AM here, it's the best > I > can do now. Good night. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/25406383-beec-4ec8-ac62-d0407a293e7e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
