[Suggestion] Use File based logger

[palantir]

[Suggestion] Use File based logger

[gatesn]

Will look to implement something similar to here: https://fangpenlin.com/posts/2012/08/26/good-logging-practice-in-python/

Sensible defaults but read logging config from file if it's available

[HerringtonDarkholme]

Actually this problem is more serious. autozimu/LanguageClient-neovim#21

It seems writing to stderr blocks writing to stdout.

[gatesn]

So the problem, as you pointed out, is that languageClient-neovim sets stderr=PIPE. What is happening is the client blocks waiting to read from stdout, Pyls fills up stderr buffer and blocks waiting to write to stderr and we end up in deadlock.

See here for more explanation:
http://stackoverflow.com/questions/1180606/using-subprocess-popen-for-process-with-large-output

What languageClient-neovim should be doing is use select to read off both stdout and stderr and then throwing away stderr if it doesn't think its relevant. Alternatively it could set stderr=None to just drop it entirely, it could redirect it to appear on the client's stderr, or it could pass in a file object to redirect stderr to disk.

I agree that Pyls should have more configurable logging and will work on implementing that, but it's not in any language server contract that logs cannot be written to stderr.

Equally changing the log level isn't sufficient as in the case there is a lot of ERROR messages it will still hang! Just happening less frequently.

So I think the solution here is for us to support configurable logging, and to make things easy for clients maybe a command line switch to redirect stderr to a file, but also for languageClient-neovim to properly handle stderr.

[HerringtonDarkholme]

I don't think LanguageClient is the same as the stackoverflow question.

Actually PYLS blocks at writing to stdout, not stderr. Recorded here autozimu/LanguageClient-neovim#21

Source:
https://github.com/palantir/python-language-server/blob/master/pyls/jsonrpc.py#L155

[gatesn]

@HerringtonDarkholme would be great to get your thoughts on this PR as a solution: #19