robotkernel status

[martinRenou]

Hi there!

cc. @datakurre @bollwyvl

We've been working for the past months on xeus-robot, which is more or less a robotkernel that works with the new JupyterLab 3 debugger (which is not possible with the kernel wrapper approach as of today). As part of this work, we've put together the robotframework-interpreter python library which implements all the robotkernel features, and make them usable as a library for xeus-robot. This work would not have been possible without the effort put in robotkernel!

https://user-images.githubusercontent.com/21197331/104568942-facc5680-5650-11eb-97cd-34695417476e.mp4

I am opening this issue to start discussing the future of those two projects. Using robotframework-interpreter in robotkernel would drastically reduce the size of the robotkernel codebase while keeping all the features.

[datakurre]

@martinRenou Thanks for the heads up! Awesome news! I'm looking forward for you to clean up our legacy at robotframework-interpreter, and then see what's the place left for robotkernel in the future. I am also happy to hear that you were able to re-use parts to get started with debuggable robot!

Unfortunately, I am not currently able to do much development on robotkernel before the summer personally. Then I'll take a fresh look on the ecosystem. The robot ecosystem has advanced a lot, and new approaches for both browser and desktop testing and automation with robotframework...

[bollwyvl]

I have demoed the xrobot kernel with the debugger in lab 3, really works pretty slick!

I have noticed that the suite model doesn't seem as aware of the notebook execution model (e.g by tracking cell id), which both this kernel and irobotframework (which I also don't get to work on much) share. If I did get to work on that, it would certainly be in other feature areas, and would love to be able to share xeus code.

I don't really think there is a "2021 jupyter/robot" roadmap... Maybe there should be!

[martinRenou]

Thanks for your responses :)

I have noticed that the suite model doesn't seem as aware of the notebook execution model (e.g by tracking cell id), which both this kernel and irobotframework (which I also don't get to work on much) share

What do you mean by "not aware of the notebook execution model"? Concerning the execution model, xeus-robot is slightly different from robotkernel, but this is very subtle. Basically, we do not recompile the entire AST of the Notebook when we execute a new cell, we just compile the AST of the code in the cell, and manually append the new keywords/imports/test cases in the test suite. This is pretty ugly but it works nicely. And I suppose it could be improved by making some contributions in robotframework directly.

[bollwyvl]

Not to be pedantic (the differences are quite subtle) but I guess, symbolically, for some C(ell) with S(ettings) and T(asks):

• C0: some ***settings*** S0
• C1: some ***tasks*** T0
• C2: some more T1, S1

robotkernel/irobotframework:

• C0: apply S0
• C1: apply S0, run T0
• C2: apply S0, S1, run T1

... I think i remember what surprised me was xrobot's behavior in C2:

• C2: apply S0, S1, run T0, run T1

I'm not sure there's a right answer, as the robot syntax itself seldom uses a "stream"-based model, and only acts against "full" documents.

[martinRenou]

Any comment is very welcome!

... I think i remember what surprised me was xrobot's behavior in C2: C2: apply S0, S1, run T0, run T1

We'd like to stay close to robotkernel's behavior, and we actually have this behavior with tests so we should have the same with tasks. I will look into it. Thanks!

and only acts against "full" documents.

Yep. That was the reason for some ugly workarounds to make the debugger and file mapping work.