Splitting into Gherkin parser + Pickle executor?

[eggyal]

Is there any intention to/interest in splitting this project into a Gherkin parser backend (that emits Pickles, as per the official project's structure) and a Pickle executor frontend such that (if so desired) the former can be swapped-out for the official shared binary?

Happy to help contribute.

[bbqsrc]

The project currently has a separate crate that implements a full Gherkin parser, https://github.com/bbqsrc/gherkin-rust.

My personal interest is in using cucumber-rust and gherkin-rust only, but I have no problems with accepting a contribution which would enable gherkin-rust to be compatible with the so-called Pickle format. 😄

Can you link to any canonical documentation on said executor and the Pickle format?

[eggyal]

Apologies, canonical documentation here.

[bbqsrc]

Okay, cool!

In the current develop branch, we have an event emitter for getting a stream of all the testing events, in order to implement new output formats. It is likely feasible that that could be hooked into as the response point for sending to the engine a meaningful response once converted from our format to the protobuf format.

However, insofar as receiving commands from their orchestrator, that seems rather out of scope for what we've developed here, and I'm not sure I see the benefits of implementing it (indeed, this Rust cucumber implementation exists because when I looked into this, I saw everything was a Go binary, baulked, and implemented my own in an afternoon instead.)

That said, I'm okay with the idea of having an opt-in feature flag for this, and having a command line flag for the generated cucumber test bundle that would put it in "orchestration" mode and receive commands via stdin. My worry is of course that it will make the code much less maintainable, but I suppose in the worst case we could work out a way to ship the orchestration compatibility in some other way.

[bbqsrc]

If you wish to have a shot at it (or anybody else for that matter!), Protobuf in Rust is a little bit painful and not my favourite thing to say the least. However, https://github.com/danburkert/prost goes a long way to making it not painful, so I would recommend starting there if you wish to start somewhere, and make a crate that just implements the .proto types first. 😄

[eggyal]

So, I confess I'm returning to this (it having been on my "interesting projects" list for well over a year) a little bit rusty and out of date from the research I'd previously conducted. Back then, the common Go binary approach had a (theoretical) advantage of enabling changes to be made to the Gherkin spec and implemented there potentially without any changes required elsewhere.

However, per cucumber/common#425 (comment), the common Go binary has since been abandoned. It appears that the approach now is to officially maintain a set of language-specific libraries that provide various components, from parsing gherkin to test orchestration, with separate language-specific projects depending on those libraries to implement only the last mile. But their design seems a bit in flux, and mimicking it at this stage would probably not have much benefit.

So I'll close this issue, but perhaps key an eye on things over there in case there's another change of approach.

[bbqsrc]

Ah, that's a shame. It's a little strange how their approaches keep changing. Do let us know if there's any changes there. 😄