Robottelo: how to refactor cli/base.py to be more flexible

[pondrejk]

Came up in a discussion at #4899

@abalakh:

Personally i don't like this approach - updating every single command with extra argument seems too much for me. @ldjebran @rochacbruno @oshtaier @svtkachenko maybe we should think about some alternatives? No ideas off the top of my head, but for me it seems like we should set extra variable/update property/introduce context manager to execute some commands without passing credentials, instead of updating every single method definition.

pondrejk:

Well, I thought the same thing, base.py should be refactored to be more flexible, how about moving the discussion to a separate issue. I wonder if we could use kwargs in this scenario.

[ldjebran]

we can use a thing like environment spaces that contain the needed env attrs and we can set the environment space context we are working on at a specific time, but the problem is more general as we have different interfaces and we want them to be more isolated, think this is an interesting area to think about for all the interfaces and not only for CLI, there is an other problem in the context of the referred tests, is that the created users are temporary ones (but this also can be solved with the right approach).
for the moment in mind as more appropriate approach is to go with a different small project that can manage all this stuff and unify all the interfaces for this usage.
This need more time to think about, but can lead to a more detailed solution.

[pondrejk]

Thought about this and I don't think it's such a big riddle, the problem with base.py is that while we can pass arbitrary options to hammer subcommands via "options" dictionary, hammer's base options (e.g. -u -p -v --interactive) are more or less hardcoded in the execute function. So what we need to do is to allow passing some hammer_options dynamically on the side of tests (if needed) + set some defaults that will keep the existing tests unaffected.

[renzon]

I agree with @pondrek. This issue fits on prototype design pattern and we could expose access to base options through an object. I wrote a little poc of this idea a while ago:

https://github.com/renzon/pytocli

I have also started a little project with it with hammer and using nailgun as inspiration:

https://github.com/renzon/airgun/blob/master/airgun/builder.py#L37

Look an interactive session

>>> from airgun.builder import Hammer
>>> # Deafault list user
>>> list_user=Hammer().user.list.order('name')
>>> str(list_user)
'hammer user list --order name'
>>> # Want hammer in verbose mode
>>> list_user.hammer.verbose()
CommandBuilder hammer: Builder for Hammer command which is parent of all other sub commands
>>> str(list_user)
'hammer -v user list --order name'

To not having to generate the entire commands I was working in a tool to parse hammer docs directly into code like this "builder.py". But once it was not priority, I haven't work with it recently.

What you guys think?

[ntkathole]

Please feel free to re-open, if this still needs fixing.