Robotframework: support custom names on resource imports

[mwalle]

This issue depends on #1999.

Adding support for custom names will solve the problem with duplicate resource filenames. See here fore more information: https://groups.google.com/d/msg/robotframework-users/0Cb215YSnG4/mWpGHi5dwUwJ

Syntax:

Import Resource  path/to/resource.txt  WITH NAME  my_resource
Resource  path/to/resource.txt  WITH NAME  my_resource

[pekkaklarck]

This is good idea but I don't consider it too high priority. If duplicate resource names are a problem, it is typically fairly easy to rename them. With libraries custom names are more important because you may want to use same library with different parameters.

[hthiery]

We have to support user keyword files for different type of devices. As long you write a test only for one device the problem does not occure, because you only import one resource. But when you start writing tests with more than one device (type) in the setup you will hit this issue.

Example:

Resourcefile: supportTypeDevice1/control.txt

*** Keywords ***
Reset Device
    Do something to reset device type 1

Resourcefile: supportTypeDevice2/control.txt

*** Keywords ***
Reset Device
    Do something to reset device type 2

Testcase-file.txt

Resource   ${RESOURCES}/supportTypeDevice1/control.txt
Resource   ${RESOURCES}/supportTypeDevice2/control.txt

*** Test Cases ***
Test1
    control.Reset Device     # want to reset device type 1
    control.Reset Device     # want to reset device type 2

With the changes we could do the following;

Testcase-file.txt

Resource   ${RESOURCES}/supportTypeDevice1/control.txt  WITH NAME  control_device_1
Resource   ${RESOURCES}/supportTypeDevice2/control.txt  WITH NAME  control_device_2

*** Test Cases ***
Test1
    control_device_1.Reset Device
    control_device_2.Reset Device

[dkindt]

This is good idea but I don't consider it too high priority. If duplicate resource names are a problem, it is typically fairly easy to rename them. With libraries custom names are more important because you may want to use same library with different parameters.

Are we still feeling this way almost 4 years later? This would be a _very_ helpful feature and I'm sure there would be plenty in the community to help? Where would I get started to even look into this?

[pekkaklarck]

Yeah, I still see this as a nice to have but not too high priority feature. That means I won't implement it myself in the foreseeable future, but I would be super happy to review and merge PR if someone else finds this more important.

I don't remember what code to start modifying, but can look at that later if needed. There are two problems implementing this, though:

• We are currently rewriting parser, and parsing related code needs to wait until the new parser is ready to be merged to master.
• Code related to imports is old and not that good. Larger rewrite would be nice but it should be separately.

[mattivityroom]

This feature does not implemented yet ?

[drchopper]

This feature does not implemented yet ?

Unfortunately, no.