robotframework icon indicating copy to clipboard operation
robotframework copied to clipboard

Resource files should be re-processed when imported

Open dangdang03 opened this issue 10 years ago • 6 comments

test procedure: import resouce 1.txt -------first time ... do some changes for resouce file(1.txt) ... import resouce 1.txt ------- second time

for the second time, the import resouce file could not update the changes to robot execution.

dangdang03 avatar Aug 12 '15 09:08 dangdang03

If I got it right, you are running a test suite that modifies the resource file. I think that is not possible (not even desirable). When running pybot, it creates a copy of all files to a temporary space and runs from there.

On Wed, Aug 12, 2015 at 10:40 AM, dangdang03 [email protected] wrote:

test procedure: import resouce 1.txt -------first time ... do some changes for resouce file(1.txt) ... import resouce 1.txt ------- second time

for the second time, the import resouce file could not update the changes to robot execution.

— Reply to this email directly or view it on GitHub https://github.com/robotframework/robotframework/issues/2099.

HelioGuilherme66 avatar Aug 12 '15 12:08 HelioGuilherme66

@HelioGuilherme66 is correct that this doesn't work because resource files are actually processed only once. They aren't copied anywhere, though, but kept in a cache in memory. It would be possible to check has the file changed on the disk before reading information from the cache, but I'm not sure is that worth the effort.

I think that libraries and variable files work this way too, but I need to test that. With libraries a similar issue was solved by introducing Reload Library keyword in RF 2.9 (#293). In that case the motivation wasn't updating library source code, but libraries themselves getting more keywords dynamically.

Could you @dangdang03 explain your underlying use cases a bit more? Is there a reason you couldn't create new resource files instead of manipulating already imported resources?

pekkaklarck avatar Aug 12 '15 13:08 pekkaklarck

After thinking about this a bit more, I believe it would be better to just not cache anything. The main reasons are the following:

  1. Importing and processing libraries and resources is so fast that I doubt caching actually saves much time. Does execution get slower if we remove cache should be measured. There could be problems with very big resource files implemented in HTML format.
  2. Cache spends memory. This is especially problematic with libs/resources that are only imported once. How much memory is saved if cache is removed should be measured.
  3. Cache makes the code more complicated. See #2105 for a recent example.
  4. Variable files aren't cached except that Python keeps them in sys.modules. See #2101 about issue suggesting that we should also ignore sys.modules.

pekkaklarck avatar Aug 14 '15 14:08 pekkaklarck

@pekkaklarck, sorry for later reply! In my use cases, I expected to create the keyword automatedly during case execution, and the keywords context may be different every time, so I expected the import resource refreshed. and I find lib code has provide this interface.

def import_resource(self, name, overwrite=True):
       self._import_resource(Resource(None, name), overwrite=overwrite)

   def _import_resource(self, import_setting, overwrite=False):
       path = self._resolve_name(import_setting)
       self._validate_not_importing_init_file(path)
       if overwrite or path not in self._kw_store.resources:
           resource = IMPORTER.import_resource(path)
           self.variables.set_from_variable_table(resource.variables, overwrite)
           user_library = UserLibrary(resource.keywords, resource.source)
           self._kw_store.resources[path] = user_library
           self._handle_imports(resource.imports)
           LOGGER.imported("Resource", user_library.name,
                           importer=import_setting.source,
                           source=path)
       else:
           LOGGER.info("Resource file '%s' already imported by suite '%s'"
                       % (path, self.suite.longname))

for the keywords lib as bellow:

def import_resource(path)
 try:
            self._namespace.import_resource(path)
 except DataError as err:
            raise RuntimeError(unicode(err))

but this interface is not open for user, the default refresh way should take effect, but it seems not.

dangdang03 avatar Aug 19 '15 10:08 dangdang03

Some thoughts about this (triggered by #2165):

  1. use cache when imported with Resource KW in *** Settings ***?
  2. optionally use cache when imported with BuiltIn.Import Resource KW (e.g. with force_reimport=False arg?
  3. how should the variable value overwriting behave in this case? 3.a) if a variable is already imported from the same resource file e.g. var_a = foo in my_resource_a.robot a KW updates to var_a = bar my_resource_a.robot is imported again with var_a = foo --> what should be the value of var_a foo or bar?

3.b) if a variable is already imported from another resource file e.g. my_resource_B.robot is imported with var_a = bar my_resource_a.robot is imported with var_a = foo --> what should be the value of var_a foo or bar?

I use resource files quite often for "overriding default values" i.e.

  1. my_test_suite.robot imports test_vars_resource.robot (e.g. var_a = bar) and some_KWs_resource.robot
  2. some_KWs_resource.robot imports default_vars.robot (e.g. var_a = foo) --> in these cases overriding var_a value would be highly undesired

yahman72 avatar Oct 09 '15 12:10 yahman72

I recently faced this same issue with RF 3.2.2, while trying to reload my variables.py-file for each test case.

The reload functionality would be really handy in the Import Variables-keyword, but as it does not support it currently, I came up with a workaround which I run in each test cases setup:

${filename} =    Evaluate     datetime.datetime.now().strftime("%H%M%S")    modules=datetime
Copy File    variables.py    ${filename}.py
Import Variables    ${filename}.py
Remove File    ${filename}.py

pahalampi avatar May 05 '21 11:05 pahalampi