nokia / RED

RED - Robot Editor
Other
339 stars 112 forks source link

XML-RPC server will be run just in time, but can't be resolved in advance #358

Open truhlikfredy opened 4 years ago

truhlikfredy commented 4 years ago

Is there a way to tell the editor and give it a list of keywords which will be present from the dynamically included XML-RPC server, but can't be resolved/verified at the moment of writing the code?

michalanglart commented 4 years ago

Hi,

yes this is possible - you need to have a xml specification file generated by robot.libdoc tool. Have a look into short paragraph titled "Using libdoc file when external library is not present locally" in RED help: http://nokia.github.io/RED/help/user_guide/project_config/libraries.html

truhlikfredy commented 4 years ago

I think that's what i'm doing however that doesn't work when even the inlucion is dynamic. The robot script still has to do Library name while this aproach invokes the robot from python where the library is included and the Robot test files do not have single Library imported. I just need to get the editor to trust that the remote library will be there when it's not even imported in the script. If add Library import to make the editor happy and working, then it will fail on runtime because now it's imported twice the static from the script which I added and the dynamic which done from the python as robot is invoked.

michalanglart commented 4 years ago

Hi,

first of all sorry for closing the issue. I've assumed my answer resolves the issue since no follow-up question appeared for over a week.

Secondly: it seems I don't understand that well, is it possible to give us some samples of code to better see the big picture?

truhlikfredy commented 4 years ago

Sorry for no follow up, for some reason I did not see the first notification.

One example of something similar: https://github.com/renode/renode/blob/master/tests/platforms/SAME70.robot

That code is given resource which defines stuff like Renode Startup keyword. That will run the platform (where the xml-rpc server will be) and then it does dynamic import of Library on its own: Import Library Remote http://localhost:${PORT_NUMBER}/

${PORT_NUMBER} is 12345 and could be considered as constant which shouldn't change. I need to make the editor trust that the Import Library will work and allow me blindly tell that remote will be there without statically including it. When I make the editor happy and add in all tests: Library Remote http://localhost:12345/ Then editor is happy, but running it on runtime will trigger the Renode Startup which will try to include it again. They are including it in this dynamic manner because they don't want to hardcode what keywords it has and let it resolve on runtime, because only on runtime the platform xml-rpc server will run and provide the API to fetch the keywords. However the API didn't change in while and it's ok to do re-resolve from time to time if it changes, so for me the resolve of the keywords like the linked blog is fine, just I need it to do one step further and trust the keywords will be there without the editor seeing static Library import.

Here is a snippet from the file which provides the keywords:

*** Keywords ***
Renode Startup
    ${SYSTEM}=          Evaluate    platform.system()    modules=platform

    ${CONFIGURATION}=  Set Variable If  not ${SKIP_RUNNING_SERVER} and ${SERVER_REMOTE_DEBUG}
    ...    Debug
    ...    ${CONFIGURATION}

    # without --hide-log the output buffers may get full and the program can hang
    # http://robotframework.org/robotframework/latest/libraries/Process.html#Standard%20output%20and%20error%20streams
    @{PARAMS}=           Create List  --robot-server-port  ${PORT_NUMBER}  --hide-log

    Run Keyword If        ${DISABLE_XWT}
    ...    Insert Into List  ${PARAMS}  0  --disable-xwt

    Run Keyword If       not ${SKIP_RUNNING_SERVER}
    ...   File Should Exist    ${DIRECTORY}/${BINARY_NAME}  msg=Robot Framework remote server binary not found (${DIRECTORY}/${BINARY_NAME}). Did you forget to build it in ${CONFIGURATION} configuration?

    # this handles starting on Linux/macOS using mono launcher
    Run Keyword If       not ${SKIP_RUNNING_SERVER} and not ${SERVER_REMOTE_DEBUG} and not '${SYSTEM}' == 'Windows'
    ...   Start Process  mono  ${BINARY_NAME}  @{PARAMS}  cwd=${DIRECTORY}

    # this handles starting on Windows without an explicit launcher
    # we use 'shell=true' to execute process from current working directory
    Run Keyword If       not ${SKIP_RUNNING_SERVER} and not ${SERVER_REMOTE_DEBUG} and '${SYSTEM}' == 'Windows'
    ...   Start Process  ${BINARY_NAME}  @{PARAMS}  cwd=${DIRECTORY}  shell=true

    Run Keyword If       not ${SKIP_RUNNING_SERVER} and ${SERVER_REMOTE_DEBUG} and not '${SYSTEM}' == 'Windows'
    ...   Start Process  mono
          ...            --debug
          ...            --debugger-agent\=transport\=dt_socket,address\=0.0.0.0:${SERVER_REMOTE_PORT},server\=y,suspend\=${SERVER_REMOTE_SUSPEND}
          ...            ${BINARY_NAME}  @{PARAMS}  cwd=${DIRECTORY}

    Run Keyword If       not ${SKIP_RUNNING_SERVER} and ${SERVER_REMOTE_DEBUG} and '${SYSTEM}' == 'Windows'
    ...    Fatal Error  Windows doesn't support server remote debug option.

    Wait Until Keyword Succeeds  60s  1s 
    ...    Import Library  Remote  http://localhost:${PORT_NUMBER}/
michalanglart commented 4 years ago

Ok, somehow I previously missed the information that you're asking about dynamically imported library through Import Library keyword.

RED does not support it at all (I've commented on similar issue here: https://github.com/nokia/RED/issues/355#issuecomment-562493959). The semi-dynamic way with the usage of variables is supported through the means of Variable Mappings: http://nokia.github.io/RED/help/user_guide/project_config/variable_mapping.html but still it requires you to explicitely put Library setting in *** Settings *** table.

All those dynamic things happening in the runtime are big pain for tools which needs to statically decide about something. In general it is impossible to find out what library (if any) will be dynamically imported only by looking at the code. You need to run it to eventually find out. In case of RED the only supported cases of dynamic nature are those about variables dynamically appearing due to Set Test/Suite/Global variable keywords, but it uses simplified heurestic and it is not always right. I've wrote longer comment on it here: https://github.com/nokia/RED/issues/195#issuecomment-375589938.

As of now there is no mechanism in which you would be able to say: "ok editor, I know you're not seeing library X but I promise it will be available".

truhlikfredy commented 4 years ago

Yes statically decide about runtime stuff is annoying, however there should be the second option and tell editor to blindly trust something will be present without it being able comprehend how. Could this made into a feature request?

michalanglart commented 4 years ago

Yeah, sure - we would need to talk about this internally.

Do you have an idea how this could be implemented? We surely need to write it down somewhere - maybe in the file itself (in comment possibly?) or in red.xml. The latter solution would be symmetrical to Variable files section where one can specify variables files which RED would take into account (although in this case those variables are available globally for every possible file out there). Any other ideas?

truhlikfredy commented 4 years ago

Yes similar to Variable files where you could select what libraries from the Referenced Libraries will be available to what file, or have them completely global (that would be ok compromise). Or use pragmas in comments to tell that specific file will trust to have a specific Library present.

michalanglart commented 4 years ago

Ok, we'll discuss it and see with what solution we can come up.

Personally I'm leaning towards those pragmas - they are closer to the source than red.xml and can be shared between different users without need to share red.xml too. Morever probably some kind of pragmas are the way to go for silencing RED validation problems locally in the source. There is a need for that however it is still not implemented and one can only globally turn of some types of problems.

We probably could utilize *** Comments *** table for that, or just some inter-code comments

truhlikfredy commented 4 years ago

That sounds great, thanks.