A follow up to the issue I opened: https://github.com/iximiuz/pq/issues/3 This PR is a step towards having a working CI/CD - only fixing clippy warnings / errors.

Edit: I fixed the warning below, @iximiuz please take a careful look there to make sure I maintained the logic there.

Note:

One error still remains which I'm currently not sure how to solve, and would like any help!

error: this loop never actually loops
   --> src/query/binary.rs:273:24
    |
273 |           let (lv, rv) = loop {
    |  ________________________^
274 | |             let (lv, rv) = match (self.left.peek(), self.right.peek()) {
275 | |                 (Some(InstantVector(lv)), Some(InstantVector(rv))) => (lv, rv),
276 | |                 (None, _) | (_, None) => return None,
...   |
301 | |             )));
302 | |         };
    | |_________^
    |
    = note: `#[deny(clippy::never_loop)]` on by default
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#never_loop

At the moment, a valid pq program must always start from a decoder step, then have 0 or 1 mapping (transform step), and then 0 or 1 query step, potentially followed by a formatter. While I don't see how multiple query steps can be added, a more generic format like decode | map | map | ... | map | query | format would make the pq language much more expressive. Actually, the very first decode step would just become a syntactic sugar for map { .0: decode }.

The change would require some moderate refactoring, of course.

ELK's Grok is a powerful and quite concise format to parse arbitrary text and structure it. pq partially reinvents it by combining a regex decoder with a map filter. But having a native Grok support would help the adoption - there are likely people already familiar with Grok.

At the moment, the string literal parser is naive. For instance, it doesn't handle escape sequences properly. nom has an example of a more robust string literal parser, so it can be adapted to suit pq use cases. However, the licensing aspect needs to be researched first. Can nom's example be just copied or it has to be copied with the license notice, or it cannot be copied at all?

PromQL has a few tens of functions whilepq currently implements just a small subset of them.

A good first issue could be adding missing functions. The implementation probably should start from extending the parser. Then writing the computation logic here. And of course adding some tests.

Hello there!

1. Currently, running cargo clippy yields:

...
error: aborting due to 4 previous errors; 56 warnings emitted

2. No formatting is enforced on new PRs.
3. Currently, there's no way of using pq without building it locally afaik, which can be a huge drawback.

Suggestion:

1. Fix all clippy warnings / errors
2. Add a GitHub Action that runs cargo clippy, cargo fmt, make test-all and make test-e2e on every PR and push to master
3. Add a GitHub Action that publishes to crates.io so that one can install it using cargo install pq (and consider packaging it to apt and such, I offered crates.io as it's the easiest option I think)