Super amazing project!

[oronsh]

Hello, I find your project so great because I haven't seen any promql parser implementations other than golang. Is this project production ready? Is it fully compatible with prometheus' promql? Thanks a lot!

[vthriller]

Is this project production ready? Is it fully compatible with prometheus' promql?

Not really. At the very least it needs more tests (especially re: whitespace handling) and lacks support for recent changes to PromQL syntax (#3). This is partially addressed in the master branch, and the rest will follow once I find time to get back to this project.

[oronsh]

I see, thank you! May I ask what is the motivation behind this project? :)

[vthriller]

Multiple reasons, actually, some of which I can no longer remember. One, for instance, was the need to work around inefficiencies in older Prometheus query processor: queries like foo{a..., b..., c...} / bar{a..., b..., c...} were executing way faster than just foo{a..., b..., c...} / bar, and I was quite fed up with either waiting for ad-hoc charts to render, or copying and editing multiple label sets just to get the charts I wanted.

[oronsh]

I understand, thanks for sharing this with me. Regardless I think that this project would be super valuable if someone wanted to write a tsdb server in rust and support promql queries ^^

[JohnnyQQQQ]

I don't want to create a new issue so that I will piggyback on this one :)

I'm currently writing a timeseries database that should be promQL compliant. This library is a good starting point for parsing query into an AST. I would love to help to get it more compliant and add missing features. While running the promQL compliance testsuite against my database I found a few things that would need to be added, like accepting numbers in their hexadecimal representation 0x3d or accepting string literals 'a simple string'.

@vthriller are you up for new contributors, or should I fork?

[vthriller]

@JohnnyQQQQ sorry for late response. I don't really know. I'm still interested in having up-to-date promql parser, but recent versions of nom are pretty finicky and hit recursion limit much earlier than before, and I'm not sure whether I want to keep going with it, resort to earlier versions or just rewrite everying in pest/chumsky/pom/combine/whatever else there is these days. (At one point I tried rewriting it using lalrpop, and it didn't go well. Can't remember the details though.)

So in short, I guess you're better off forking, but PRs with smaller fixes are still welcome.