Allow getting fixed/converted file on stdout

[kwesolowski]

Similar to clang-format behavior when one can select in place or stdout as target.

It would give more flexibility when integrated into bigger tool suite (i.e. code format, fix include guards in single pass).

[cgmb]

Interesting. I hadn't thought of that sort of use, but it's a good idea.

[kwesolowski]

Great - let me know if you have time to take it on or you want pull request. How long it would take after PR merge to release new version to pip?

[cgmb]

I am pretty busy, but I'm not sure it makes much difference who does it. The code should be simple enough, so the real work is figuring out the interface design. Whether I'm writing or reviewing, I'll need to give a little thought to what that argument should look like and what the behaviour should be when more than one input file is given.

Proper support for tool integration should probably also include accepting input from stdin. That's a little more tricky because the file path is usually important. I see that clang-format has an -assume-filename= option to deal with this. That's an ok solution, I guess. So, we'd have --assume-filepath=.

I'll give it some thought and maybe put something together this weekend.

[kwesolowski]

Sounds good - I do not think we need to handle any multifile/recursive scenarios with this approach (clang does not afair).

[cgmb]

I figure I'll add --stdio and --assume-filepath=<file> flags to all utilities.

[kwesolowski]

Small addition - Maybe separate stdin with assumed file path and stdout? This is then easy to create code that verifies that processing has been done (ie. When I use guard once in commit hook, I will create server side check that it was run, so I can pass existing file server side instead of stdin, but I do not want modifications in place because checkout dir is no wiped clean after checks)

…

On Wed, Jan 31, 2018, 01:32 Cory Bloor ***@***.***> wrote: I figure I'll add --stdio and --assume-filepath=<file> flags to all utilities. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFr7bzJVwF6Vm-PJSWxOjjQ86BwIFwXjks5tP7SFgaJpZM4Rkd7Y> .

[cgmb]

Good point. Taking input on stdin would pretty much force you to use --assume-filepath=<path>, which is annoying if you don't really care about getting input via stdin. I added a standalone --stdout option in v2.3.0.

Input on stdin was cut because it required some refactoring to fit in, and I don't have time right now to test everything it would touch. I should probably write more automated tests, because manually testing across three platforms and two Python versions is a real pain!

[kwesolowski]

Awesome, that's the part I needed :)

…

On Wed, Feb 7, 2018, 05:54 Cory Bloor ***@***.***> wrote: Good point. Taking input on stdin would pretty much force you to use --assume-filepath=<path>, which is annoying if you don't really care about getting input via stdin. I added a standalone --stdout option in v2.3.0. Input on stdin was cut because it required some refactoring to fit in, and I don't have time right now to test everything it would touch. I should probably write more automated tests, because manually testing across three platforms and two Python versions is a real pain! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFr7b9PAIejSMIBRrnK21hmEDCQ3QT2Iks5tSSybgaJpZM4Rkd7Y> .

-- Pozdrawiam / Best regards, Krzysztof Wesolowski tel. +48 721 337 238 http://www.rainlabs.eu