Issue 1087: support dictConfig logging configuration

[MatMoore]

Hi,

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.

@roboslone @berkerpeksag what are your thoughts?

[berkerpeksag]

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?

[berkerpeksag]

Haven't played with the patch yet, but perhaps we should update CONFIG_DEFAULTS first and then pass it to dictConfig?

[MatMoore]

Yep, using dictConfig for the default case seems sensible, at least if fileConfig will be eventually removed. I'll take a closer look at this.

[MatMoore]

I misunderstood your comment earlier, but I've implemented this now (i.e. the defaults will be applied regardless of whether dictConfig or fileConfig is used). As far as I can tell the format is the same for both.

[benoitc]

Thanks for the patch!

Do we really need another config setting? It seems that you can only pass the dictConfig via the config file. So we can probably only check it instead and accept it.

Also in case you didn't notice it the CI is broken with the current patch:

    def validate_dict(val):
        if not isinstance(val, dict):
>           raise TypeError("Value is not a dictionary: %s " % val)
E           TypeError: Value is not a dictionary: None

[MatMoore]

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.

[MatMoore]

Something I didn't realise earlier is that dictConfig wasn't added until 2.7, so I've modified my changes to ignore the new setting on older versions. Do you want me to still put a deprecation notice for --logconfig?

[berkerpeksag]

I think we can print a user friendly message if dictConfig is None instead of silently ignore the problem. I will review this more carefully soon. Sorry for my late response!

[MatMoore]

No problem :) I think making dictConfig an error on 2.6 and below would probably be best, but I'll wait until you're done with the review before changing anything.

[benoitc]

bump ? What is needed to close that PR?

[berkerpeksag]

I need some time to review this. I can't make any promise for 19.7, but I'll review it eventually :)

[benoitc]

@berkerpeksag thanks :)

[MatMoore]

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.

[benoitc]

@berkerpeksag reopened after #1572 discussion. What do you think we should do there to apply it?

[aconrad]

Would anyone mind to update this PR with the latest master to fix the coverage report?

[tilgovi]

Rebased. See #1602.