Import Failure when Library resource has a variable

[Catoakido]

Import Error on Windows Sublime 3114, Robot Framework Assistant 4.1.0 when a variable is in the Library resources

Example:

*** Settings ***
Resource         ../resources/resources.txt
Resource         ../resources/object_repository.txt
Resource         ../resources/keywords.txt
Resource         ../resources/${res_LAB}.txt

When Create Database is run, the log file reports an import error (from scan_index.log)
('Import failure on file: c:\\users\\user\\documents\\_robotwork\\selfcare\\test_cases\\testscript.txt,', 'could not locate: ../resources/${res_LAB}.txt')
Curiously, we tried adding${res_LAB} to "robot_framework_builtin_variables": to see if it gets ignored, but no luck

Here is the User Settings file:

{
    "extensions":
    [
        "txt"
    ],

    /*
        Robot Framework Workspace

    Defines a root folder where Test Suite located. 
    Before the Robot Framework Assistant can provide the keyword 
    and variable completion features, it needs to scan and index 
    the test suite and resource files. The argument defines the root folder 
    where scanning of robot data is performed.

    In windows the backslash is the folder separator and in json
    backslash is the escape character. Therefore, in windows write
    double backslash to write literal backslash.

    Linux example: "/home/User/myRobotTests"
    Windows example: "c:\\Users\\User\\Desktop\\myRobotTests"

    */
    "robot_framework_workspace": "C:\\Users\\user\\Documents\\_robotwork\\suite\\test_cases",

    /*
        File extension defines which types of files the Robot Framework
        Assistant plugin will search and index from the folder defined
        in the robot_framework_workspace option.

        This setting does not affect to the which files are uses the
        syntax highlight.
    */

    "robot_framework_extension": "txt",

    /*
        Path to Python binary

        In order the scanning and indexing of keywords and variables to
        work, path to Python binary must be defined. It must be the same
        Python binary where the Robot Framework is installed.

        In Linux like environments this could be like: /usr/bin/python
        and in Windows this could be like: C:\Python27\python.exe
    */

    "path_to_python": "C:\\Python27\\python.exe",

    /*
        Module search path defines a list of paths where the
        Robot Framework libraries are searched. Example if you have imported
        a library with the library name, then module search path must
        contain the folder where the library can be located.

        The Robot Framework Assistant uses the Robot Framework API to parse
        the test data and libraries. All changes, which are not system
        wide, to locate the libraries, must also be added in the
        module search path in the Robot Framework Assistant

        More details how libraries is searched in Robot Framework can be
        found from be the Robot Framework User guide:
        http://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.html#module-search-path

    */
    "robot_framework_module_search_path":
        [
            "C:\\Python27\\libs",
            "C:\\Python27\\Lib\\site-packages",
        ],

    /*
        Robot Framework variables

        Robot Framework comes by default some predefined and built in
        variables. These variables names may change between different
        Robot Framework versions. Use this setting to define the
        Robot Framework default variables.

        The variables in the default settings are from Robot Framework
        version 2.9.2

    */
    "robot_framework_builtin_variables":
        [
            "${/}",
            "${:}",
            "${\\n}",
            "${CURDIR}",
            "${DEBUG_FILE}",
            "${EMPTY}",
            "@{EMPTY}",
            "&{EMPTY}",
            "${EXECDIR}",
            "${False}",
            "${LOG_FILE}",
            "${LOG_LEVEL}",
            "${None}",
            "${null}",
            "${OUTPUT_DIR}",
            "${OUTPUT_FILE}",
            "${PREV_TEST_MESSAGE}",
            "${PREV_TEST_NAME}",
            "${PREV_TEST_STATUS}",
            "${REPORT_FILE}",
            "${SPACE}",
            "${SUITE_DOCUMENTATION}",
            "${SUITE_NAME}",
            "${SUITE_SOURCE}",
            "${TEMPDIR}",
            "${TEST_DOCUMENTATION}",
            "${TEST_NAME}",
            "${True}",
            "&{SUITE_METADATA}",
            "@{TEST_TAGS}",
            "${res_LAB}"
        ],
}

[aaltat]

This is by design and correct behaviour. To be able to know the value of the ${res_LAB} variable, plugin should run the tests. The plugin only parses the data and is not able know what values the variable contains.

This can be improved and I am open to ideas (and pull request) to improve the plugin.

[aaltat]

Is this still a problem for you and do you have an opinion how it should be improved? Or can we close the issue?

[Catoakido]

In Sublime 2, this seemed to work. When clicking a variable which maps to value set in ${res_LAB}, it would list all the files with that variable. Then, I would manually select which one I was interested in.

Improvement Suggestion:
Is there an setting or option where we can ignore this error when building the database? As is stands, the database never gets fully built thus leaving most items missed. It would be good to just log the errors seen and let the database be built as much as possible.

Secondly, can there be a setting in the plugin to point to a folder where all my resource files are located? (Maybe you already have that and I missed it) The database builder would ignore any Library declarations in the script and build a database based on whatever is in the folder instead.

On Jul 16, 2016, at 03:56, Tatu Aalto notifications@github.com wrote:

Is this still a problem for you and do you have an opinion how it should be improved? Or can we close the issue?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #152 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ATRZh7A_lNZSjvm9E8OOY6XPJKJD3wFvks5qWJy-gaJpZM4JBMPz.

[aaltat]

1. Also the jump to variable source is a feature which does not exist in this version of plugin. Mainly because I haven't found a time to implement it, but it's a good feature. Could you write a separate issue about the jump to variable source.

2. For the improvement ideas, that is how the plugin currently works. Reading the Creating a database from README and internal database description from wiki should give a better description how to plugin works.

There is major difference between the 1.x.x and the current version. The 1.x.x version would offer keyword completion from all found resources and libraries, regardless was the resource or library actually imported. The latest version actually offers keyword completion from resources and libraries which user have actually imported (in current or child files). Because your resource import parsing fails, because it contains a variable in the file path, the plugin can't provide keyword completion from that file or any of the child imports.

There are many ways to solve the problem:
a) Make configurable how imports are resolved. In old or new way.

b) Manually configure variable(s) content to settings, so that resource or library can be implemented.

c) Also parse automatically content.

d) Combination of the b&c.

But I am open to new ideas and suggestions how to fix the problem.

[Tattoo]

For a fairly large RF project, using variables in Resources and Libraries is (in my opinion) a best practice:

Resource     ${RESOURCE ROOT}${/}path${/}to${/}my_resource.robot
Library      ${LIB ROOT}${/}mylib.py

I personally would be happy with just option b, ie. having the ability to define those few variables I need for imports to work. Maybe having a dict in Settings file, where you can define "project variables" and those are replaced when building a database?

I could also take a stab at it, if you can point me to correct direction.

[aaltat]

I have been thinking to same direction, b, would be the best way to go. I am away from my PC (holidays) but as a quick look https://github.com/andriyko/sublime-robot-framework-assistant/blob/master/dataparser/data_parser/data_parser.py would be good place to start. The only problem on this is that the data_parser object is independent from Sublime and accessing the Sublime settings, to read the correct variable value can be problematic. But if that problem can be solved, then I would take this route.

[aaltat]

@Tattoo If you are still interested to make this, there has been quite lot of refactoring on the internal database functionality. Therefore it might be good idea to rebase with the master.

[aaltat]

I have been thinking this problem and perhaps it would be best to define the variable values in the (user) settings file. Then when creating the internal database write the variable values to a file. Then when process which creates the database tables, take the file as argument and when scanning would replace the values during the scanning process.