Importing variables not working?

Hello all,

I was just testing an old file from 2016 and tests failed with unexpected variable not defined. Can you please confirm this? Thanks.

Execution on Fedora Linux 34 with Robot 4.1.2:

robot external_vars_test.robot 
==============================================================================
External Vars Test :: A test file using external variables. Created on 3/14...
==============================================================================
Today is 3.14 2016 Pi day :: Testing external variables               | FAIL |
Variable '${name}' not found. Did you mean:
    ${TEST_NAME}
------------------------------------------------------------------------------

This is output from Python 3.9.7:

>>> from external_vars import *
>>> print(name)
Archimedes

This is the variable file:

from math import pi

name = "Archimedes"
city = "Syracuse"
radius = 6.5
better_Pi = pi
# DATA = "this is argument: %s" % args[0]


def get_variables(args=None):
        DATA = {"data" : "this is argument: %s" % args}
        return DATA

And this is the test case:

*** Settings ***
Documentation     A test file using external variables.
...               Created on 3/14/2016.
...               Another line added on 8/9/2017 (to see ...)
Variables         ${CURDIR}/external_vars.py
Library           OperatingSystem    WITH NAME    OS

*** Variables ***
${PI_DAY}         3.1416

*** Test Cases ***
Today is 3.14 2016 Pi day
    [Documentation]    Testing external variables
    Log    Today is Pi day celebration\nThis is the basic value of Pi: ${PI_DAY}
    Log    Pi was calculated by ${name} from ${city}
    Log    The Python's value of Pi is: ${better Pi}
    ${my area}=    Evaluate    2*${PI_DAY}*${radius}**2
    ${better_area}    Evaluate    2*${better Pi}*${radius}**2
    ${error}=    Evaluate    ${better area}-${my area}
    Log    An example of the use of Pi is to calculate the area of a circle.\n We have a circle with radius = ${radius} units. We get ${my area} and ${better area} depending of the accuracy of the value of Pi.\n As we can see, the error is ${error}.\n One more line.\n    WARN
    Log Variables
    Log    Second editing example of the use of Pi is to calculate the area of a circle.\n We have a circle with radius = ${radius} units. We get ${my area} and ${better area} depending of the accuracy of the value of Pi.\n As we can see, the error is ${error}.\n One more line.\n
    Log To Console    This message goes only to Console.
    No Operation
    Log Many
    Comment    No Operation \    The Python's value of Pi is: ${better Pi}
    Log    This message goes only to Console.
    Log To Console    ${PREV_TEST_STATUS}
    Comment
    Set Environment Variable    HTTP_TEST    abcde

Set env var
    ${HTTP_TEST}=    Get Environment Variable    HTTP_TEST    This is the default
    Set Environment Variable    HTTP_TEST    ${HTTP_TEST}
    Log    %{HTTP_TEST}
    Log    ${PI_DAY}

Show env var
    Log    %{HTTP_TEST}
    Log    ${PI_DAY}

That variable file has get_variables so variables are got by calling it, not from the file directly. This behavior hasn’t changed.

I was not aware of that special function.
But is was working without calling it (or am I wrong?).

Indeed, commenting that definition of get_variables, makes the test pass.

This is a strange effect. I created a function with special meaning.

The User Guide explains how that function works in detail. It has been supported for ages.

Well, I started by saying that is a test from 2016. I just got surprised by the normal variables definitions stopped working when that function exists. In my view they could co-exist.

I think get_variables has been supported already before RF was open sourced. Couldn’t easily find references when it was added, but it certainly existed in 2009 because it was enhanced in RF 2.5:

I don’t think it could really co-exist with normal variables. A major problem normal variables, i.e. reading them directly from the variable file module, is that nearly everything becomes a variable. get_variables is one way to avoid that. In addition to losing that functionality, changing this would be very badly backwards incompatible.

Thanks. I probably added the function later to my initial test. Will see if my keyword work or if it is ignored and superseded by the builtin.