here’s a small summary of the 12th (coding) week. The last week I continued
the work on the new user interface. As a result the “request” command is more
or less implemented. Yesterday I pushed the current code and it’s also possible
to play around with it:
- checkout the code 
- cd osc2/osc/cli
- export PYTHONPATH=/path/to/osc2
- python cli.py -h (for more information)
In order to list a request it is sufficient to run
“python cli.py request api://your_project” (Note: all https requests are
_insecure_ – so far the certificate etc. is not checked).
Some implementation details:
In my last mail/post I described how a new (sub)command can be specified
so I’ll leave out the details here.
In the following I’ll shortly explain how the arguments specified by the
user at the commandline are passed to a function (which does the actual
work – like listing the requests).
class RequestList(CommandDescription, Request): """ ... """ cmd = 'list' args = 'api://project?/package?' opt_user = Option('U', 'user', 'list only requests for USER') func = call(request.list)
As we can see the project and package parameters are optional. After
the parsing process a so called “info” object is returned which encapsulates
the specified arguments. Assume the user runs “request list api://test_prj”
then the info object has the following attributes:
info.apiurl = the default apiurl info.project = 'test_prj' info.package = None
The question is how can we pass this data to the request.list function?
A simple (and naive) approach would be to simply pass the “info” object
to the request.list function that is “list” has the following signature
“def list(info)”. As a consequence inside the method we always have to
use “info.project”, “info.package” etc. which is a bit awkward – at least
for parameters which are quite frequently used in the method definition.
So it would be nice if there’s a way to pass frequently used parameters
directly to the method (that is they’re declared as formal parameters
in the method definition) and infrequently used parameters can still be
accessed via the info object. Exactly like this it is currently
implementend in osc2.
So the following signatures would be correct for our example:
def list(project, package, info) def list(project, package, user) def list(project, package, user, info) def list(project, info) def list(info, project) def list(project) # using the info object is not mandatory def list() # quite useless... ...
def list(prj, pkg, info) def list(foo, info) ...
So it is up to the developer how to define the signature of the
request.list function – it is not completely dictated by osc:)
Both comments and pings are currently closed.