There is no way to use a resource from another namespace

[Zygmunt Krynicki]

Job definitions may have the so-called resource requirements. Those are python-like expressions (parsed with python's ast module) that prevent a job from running unless there is a resource record with a particular name, that has at least one object that causes the resource expression to evaluate to true. This is documented in [1].

The way plainbox infers the name of the resource record to look up from the python-like identifier used inside the expression is limiting. Traditionally it prevented resources to follow the "group/name" pattern since "/" cannot be used in python identifiers. Now the problem is more serious since it also prevents us from reaching out to resources from other provider namespaces.

This severely limits other tests authors and prevents them from using common resources such as 'device' and 'package', that ship with checkbox.

[1] http://plainbox.readthedocs.org/en/latest/dev/resources.html

[Zygmunt Krynicki (zyga)]

I'd like to propose that we allow test authors to use this new syntax to refer to arbitrary job identifiers as resource containers:

package = resource("2013.com.canonical.certification::package")
package.name == "checkbox"

The resource identifier would become a implicit / builtin callable that would be picked up by the resource program analyzer and in turn would make the identifier 'package' refer to the job with the full id given as argument.

As an extension to this method, if the argument to resource() is not a fully qualified job identifier, then implicit namespace of the encompassing provider will be automatically used to construct the full identifier. This would match the existing convention of only having to use full job identifiers when spanning namespace boundaries.

[Daniel Manrique (roadmr)]

If not assigned to anyone, it can't be in progress :P