resource handling and "namespaces"

[Michael Walle]

Hi all,

we have a very extensive resources "library" which offers user-defined
keywords for common tasks. I fear we will soon reach the limit of
robot's resource import handling.

Our directory structure looks like:

resources/feature-a/common.txt
resources/feature-a/subfeature-1.txt
resources/feature-a/subfeature-2.txt
resources/feature-b/common.txt
resources/feature-b/another-subfeature-1.txt
resources/feature-b/another-subfeature-2.txt

Using the features mutually exclusive in tests works, but as soon as you
want to use both feature-a/common.txt and feature-b/common.txt you will
have a problem if these resources also have the same keywords.

Our import looks like
***Settings***
Resource ${RESOURCES}/feature-a/common.txt

and therefore the full keyword name is
common.Keyword

So if "Keyword" is available in feature-a/common.txt and
feature-b/common.txt this name is not unique anymore. Unfortunatly, i
don't see any practical solution (yet). We could rename the common.txt
and requiring unique resource file names, but this would make nonsense
of directories. If there would be a "WITH NAME" option for resource
imports, we could work around our issue. For example

Resource ${RESOURCES}/feature-a/common.txt WITH NAME
feature-a-common

Sadly, there is no such option. Personally, i would prefer something
like:

Resource feature-a/common.txt

which then will imports its keywords with a feature-a.common prefix (eg.
feature-a.common.keyword). Of course you would need something like a
resource search path, but the advantage will be that you can
automatically build a prefix for each keyword. I can imagine that this
does not play nicely with the fact that the resource imports are global
at the moment ;)

Any other ideas?

-michael

[Tatu Aalto]

Ugh

If the keywords are really common (have same name and do the same thing), is there are good reason keep those keyword under a specific feature. Would the better place for them be in resource/something/name.robot file?

And as a person note, calling something with name common is not good practice. I have shot myself in the leg few times, when calling something with name common. Usually it comes thrash can for thing's which do not have a good name.

-Tatu
Send from my mobile

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-users+unsub...@googlegroups.com.
To post to this group, send email to robotframework-users@googlegroups.com.
Visit this group at http://groups.google.com/group/robotframework-users.
For more options, visit https://groups.google.com/d/optout.

[Michael Walle]

Am 2014-12-18 16:45, schrieb Tatu Aalto:
> Ugh
>
> If the keywords are really common (have same name and do the same
> thing), is there are good reason keep those keyword under a specific
> feature. Would the better place for them be in
> resource/something/name.robot file?
>
> And as a person note, calling something with name common is not good
> practice. I have shot myself in the leg few times, when calling
> something with name common. Usually it comes thrash can for thing's
> which do not have a good name.

That was just an example. Renaming, of course, solves our problem. But i
consider this just a workaround because if we would do it that way we
could also keep our resource files flat in one directory and thus
enforcing the rule "unique file name". But i want to keep my files
organized and sooner or later there will be a name clash which i cannot
fix other then renaming the file.

-michael

[Michael Walle]

Ping.

Could any robotframework developer give a thought on this? I bet sooner
or later there will also be other people which faces the same problem.
Esp. companies which keep a central repository of resources shared among
their project.

-michael

[Michael Walle]

anyone? :(

-michael