Hi, 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 [1] - cd osc2/osc/cli - export PYTHONPATH=/path/to/osc2 - python cli.py -h (for more information) Example: 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... ... Invalid signatures: 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:) Marcus [1] https://github.com/openSUSE/osc2 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org