RED
RED copied to clipboard
nokia
Future development to support RF >3.2
Dear reader,
I try to use RobotFramework 4.0b1 and latest RED, but unfortunately it seems that it doesn’t load the Builtin-Libraries. E.g. it writes “unknown keyword ‘log’”. Unchanged workspace with e.g. 3.2.1 RobotFramework works without issue.
I’m happy for any idea how to solve this issue because I would like to stay with the 4.0 version.
Thank you, Thomas
This is related to: https://forum.robotframework.org/t/red-doesnt-find-builtin-libraries-with-robotframework-4-0b1/1100/3?u=thpoll
@michalanglart the Beta1 should be in a state that you can have a look how it is build.
you basically have to maintain two things.
first:
Arguments are not longer a list of string representations. they are now structured.
But you can just access the //arguments/arg[repr] attribute. It will contain same content that was before in
<kw name="Click" source=".pyenv/versions/3.8.0/lib/python3.8/site-packages/Browser/keywords/interaction.py" lineno="252">
<arguments repr="selector: str, button: MouseButton = left, clickCount: int = 1, delay: timedelta | None = None, position_x: float | None = None, position_y: float | None = None, force: bool = False, noWaitAfter: bool = False, *modifiers: KeyboardModifier">
<arg kind="POSITIONAL_OR_NAMED" required="true" repr="selector: str">
<name>selector</name>
<type>str</type>
</arg>
<arg kind="POSITIONAL_OR_NAMED" required="false" repr="button: MouseButton = left">
<name>button</name>
<type>MouseButton</type>
<default>left</default>
</arg>
<arg kind="POSITIONAL_OR_NAMED" required="false" repr="clickCount: int = 1">
<name>clickCount</name>
<type>int</type>
<default>1</default>
</arg>
<arg kind="POSITIONAL_OR_NAMED" required="false" repr="delay: timedelta | None = None">
<name>delay</name>
<type>timedelta</type>
<type>None</type>
<default>None</default>
</arg>
<arg kind="POSITIONAL_OR_NAMED" required="false" repr="position_x: float | None = None">
<name>position_x</name>
<type>float</type>
<type>None</type>
<default>None</default>
</arg>
<arg kind="POSITIONAL_OR_NAMED" required="false" repr="position_y: float | None = None">
<name>position_y</name>
<type>float</type>
<type>None</type>
<default>None</default>
</arg>
<arg kind="POSITIONAL_OR_NAMED" required="false" repr="force: bool = False">
<name>force</name>
<type>bool</type>
<default>False</default>
</arg>
<arg kind="POSITIONAL_OR_NAMED" required="false" repr="noWaitAfter: bool = False">
<name>noWaitAfter</name>
<type>bool</type>
<default>False</default>
</arg>
<arg kind="VAR_POSITIONAL" required="false" repr="*modifiers: KeyboardModifier">
<name>modifiers</name>
<type>KeyboardModifier</type>
</arg>
</arguments>
<doc>Simulates mouse click on the element found by ``selector``.</doc>
<shortdoc>Simulates mouse click on the element found by ``selector``.</shortdoc>
<tags>
<tag>PageContent</tag>
<tag>Setter</tag>
</tags>
</kw>
Thanks René @Snooz82!
I had a look. It does not seem complicated too much although we cannot just change our existing implementation as we did between version 1 and 2 of specifications as the structure changes too much. Since we want to support both 3.x and 4.0 we need to provide two implementations and hide them behind the interfaces so that they would behave the same from the perspective of the code which uses that.
Hi both, thank you for your comments. Looks like I wait for a solution for this issue. Please inform me when a solution is there. I would support testing. You can also give me test builds. Thomas
Hi,
I hope the support to some extent should be possible probably around the time RF 4.0 would be released. However I'm not sure yet about handling all the new syntax.
Hi team,
We were researching for known compatibility challenges with RF 4.0 + RED and we discovered this issue.
One of our testers was having a problem specifically with RF 4.0b3:
Let me know if this is a different problem and I will raise a separate issue.
RF 4.0 officially releases next week although it will be a while yet before our company adopts RF 4.0 as the default version.
Are you able to indicate when RED might have a compatible version?
Thanks, Adrian
Can't tell now, sorry.
We're very busy with other projects currently. We should have some time for RED in coming weeks and some work was already done for RF 4.0 but as of now I don't know yet how much work is needed.
Robot Framework 4.0 is a new major release with lot of big new feature, Please Make RED supporting RF 4.0 ASAP
UP
You made an excellent work on RED guys, it's really got the best UX for Robot. Unfortunately, we couldn't upgrade to RF4 until RED fully support it.
UPDATE: Robot Framework 4.0 was officially released 11.3.2021: https://github.com/robotframework/robotframework/releases
@michalanglart : I believe there be a few changes for RED in order to be compatible with RF 4.0. Is there anything the community can do to help? Post it here and you might get support.
We are stuck on robotframework 3.2.2 and hopefully RED will support 4.0 soon.
Cheers.
+1 add RED support for RF 4.0.
RED is such a useful tool, but RF 4 brings a ton of useful features so upgrading is quite appealing.
https://github.com/nokia/RED/issues/421#issuecomment-828214352 An official message that they will start development for RF4.0 👍
No, there is no solution until RED will support RF 4.0
The PR 418 will only make this exception disappear but there are more changes in RF 4.0 which requires RED to change in order to properly run tests.
We're about to start development for RF4.0
i hope RED development started already. Expecting the fixed version of RED sooner so that we can move to make use of RF 4.x
Can someone from the development team please tell us the current status and when will Red be supported
For those of you following this issue, if your needs are urgent then you may wish to explore alternatives until RF4 compatible RED becomes available.
One popular alternative is Robot Framework Language Server which is available as an extension in VS Code: https://robocorp.com/docs/developer-tools/visual-studio-code/lsp-extension#what-is-the-language-server-protocol-lsp-and-why-is-it-useful
@valentijnpeters submit a PR quoting this issue perhaps? Check the comment from René (Snooz82) above for some guidance. Even if the RED team don't merge your changes it might help them identify code that needs refactoring.
We also had to make a few changes to our internal "RF Bulk Test Runner" tool due to changes in the api but in our case they were quite trivial. For example, the test.keywords collection is now test.body.