Adds Windows Scoop instructions for fq in README.

[thushan]

Adds instructions to installing fq from scoop which I added recently.

(ignore the warnings, this is a fresh install of Windows)

We had some difficulty with licenses as fq isn't officially marked as MIT (even though the LICENSE file text is MIT).

[wader]

Thanks! what could be added to the README to mark it as MIT? a license section somehow?

[thushan]

Easiest is to specify the license at the top of the LICENSE file like fd does and expand the README to mention that specifically.

(I can't do that though!) If you ping here, I'll update the scoop package for the license details later :)

[wader]

Ok! not sure why that header got left out. No problem I will add that and ping you

[wader]

And let me know if there is something i can do to make fq more windows friendly. I don't use windows much myself so any help with that is much appreciated

[thushan]

I don't use it much either now but will let you know!

Hopefully this makes it more accessible to those on Windows! (I needed it for a Windows build agent) but we primarily use it on Arch.

Thanks for updating license, I'll add another PR back to Scoop to fix it properly.

[wader]

I see 👍

Using fq in some kind of tests? a bit curious what people use it for :)

[thushan]

Ah yes, a customer has various media files that run through a process and we analyse the output using fq (instead of I think initially 8 other tools - some of which are proprietary!) to ensure the right output was generated. The testers can simply write queries like a unit test and being output to Json makes it easier for subsequent tooling too.

Precisely the reason why you came up with fq it seems and they're finding it super useful - well the testers are now. Being written in Go makes my life easier to add support for a new format and PR back too.

Oops, and if you didn't hear the scoop, the license stuff was fixed in Scoop by Rashil (on Scoop land).

[wader]

Ah yes, a customer has various media files that run through a process and we analyse the output using fq (instead of I think initially 8 other tools - some of which are proprietary!) to ensure the right output was generated. The testers can simply write queries like a unit test and being output to Json makes it easier for subsequent tooling too.

Precisely the reason why you came up with fq it seems and they're finding it super useful - well the testers are now. Being written in Go makes my life easier to add support for a new format and PR back too.

Yeap sounds very similar reason. I haven't used it in a CI environment yet but will probably happen, i've mostly used it to debug media files and during software development... and just general curiosity how things work.

About the testers, do they write complex queries or scripts or mostly output some part of the file as JSON etc and compare or process it further in something else? Im thinking what kind of documentation i should focus on, it's a bit sparse at the moment.

Can you say something what format that are used?

No worries if you don't feel comfortable to answer or can't give any details.

PR's are very welcome! let me know if you want any assistance.

BTW if you'r using some specific feature or part of some format one idea might be to add test files and fqtest for those. Would make it less likely to break something or make it possible to add release notes if something will change.

Oops, and if you didn't hear the scoop, the license stuff was fixed in Scoop by Rashil (on Scoop land).

👍 Great!