Feature request: Make Robot Framework dependency optional

[mikahanninen]

The benefit from this would be that this package would be usable even when ran as a pure Python package without Robot Framework module thus increasing its usability and popularity.

For example keyword Input Password will fail when running python myselenium_tests.py (ie. without robot module), because keyword is modifying Robot Framework log levels.

robot.libraries.BuiltIn.RobotNotRunningError: Cannot access execution context

[emanlove]

The short answer is no. This is and always has been intended to be a Robot Framework library. It has not been intended to be a standalone Python framework for Selenium that can be wrapped by Robot Framework. Robot Framework is the ecosystem for this project. There are python based Selenium frameworks, like SeleniumBase, if one wants a purely python solution. Or one can write their own.

Removing Robot Framework as a dependency and supporting it as both a Robot Framework ecosystem project and a Python ecosystem project would be a significant increase in the required level of development and support. Our focus is on Robot Framework and that is where we choose to put our energy and passion. If Robot Framework would lose popularity or eventually fade away then so be it. We would move on. But for now this will remain a Robot Framework Library.

[emanlove]

Let me add for all .. I see this as a legitimate request and it has its merits, but again the answer is no.

[mikahanninen]

The wording on my issue was maybe a bit too vague. The optionality I was talking about was about lessening tight coupling to Robot Framework during runtime and not about making robotframework package optional. Changes to keyword implementation so that keywords would still function even if code has not been run with python -m robot, ie not failing when BuiltIn().set_log_level("NONE") is not possible.

But I can understand the stand here. From rpaframework point of view we will see if we can still make the SeleniumLibrary work for us, if not then we go in another direction.

[emanlove]

Chatted briefly with Tatu about this. I see that I may be overlooking something here in your request. But at this time even looking into this does not fit into my schedule. And even if we were to remove that runtime dependency I can't guarantee that we would match an external schedule or external priorities so I am not sure how helpful this is. As I recall the selenium portion of rpaframework, when I last saw the code, had already diverged and was really its own codebase and selenium python implementation. That appears to have been removed in the current codebase and I am not going to spend any time looking into and trying to understand the current implementation. But if someone wants to layout the history and implementation of rpaframework selenium I am willing to listen.