Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Issue 1087: support dictConfig logging configuration #1110
This PR is a proof of concept for issue #1087.
So far I have only done a brief test, and I am not too familiar with the existing config implementation, but I will happily look into this in more detail and clean it up if I can get some feedback on the approach taken.
As pointed out in the linked issue, dictConfig enables certain functionality that is not available through the older fileConfig interface.
I've kept the new option separate from --config for backwards compatibility, but dictConfig takes precedence. I don't know whether --config should be entirely deprecated though.
Thanks for the PR, @MatMoore :) This approach looks good to me. I'll review it more closely soon.
I don't think we should touch --config, but I'm in favor of deprecating --logconfig. Having a separate and outdated setting(also a separate file) for logging configuration is not a good a thing for users :)
I also would like to disable passing --dictconfig since it makes no sense and it confuses users. Is there a simple way to do this, @benoitc?
Thanks for the patch!
Do we really need another config setting? It seems that you can only pass the
Also in case you didn't notice it the CI is broken with the current patch:
Doh, sorry about that - this was very rushed, but I'll try to spend some more time on it this weekend (and I'll make the tests pass this time!)
@benoitc Could you clarify what you mean by only check it and accept it? With the new settings object I was only planning on using it for basic validation and documentation, not cli options, so I can do it differently if there's a simpler way?
I suppose we could also reuse logconfig for the dictConfig version, while still supporting the deprecated file values, but it doesn't seem like the setting metaclass was designed for this usage.
@berkerpeksag Oops, --logconfig was the one I meant :) Happy to go down the deprecation route if that's the consensus.
Hi, I'm going to close the PR as I don't personally need the feature any more and I'm not particularly engaged with making sure it gets into gunicorn. In the meantime it just clutters my open PRs list.
@benoitc if the change is still useful feel free to raise it again as a new PR. Thanks for following up on this.