-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Start work on alternative client #122
Conversation
This client will have nicer user interface. The client allows loading plugins from predefined directories so that implementing internal extensions is possible. So far, listing, retrieving, creating and updating releases is possible. Ultimately, the PDCClient class should be moved to a separate module, so that it is accessible for other users. It abstracts the reading the client configuration file and obtaining token. Another thing that must be improved is the help - currently all commands with help are shown with --help, and commands without help are not shown at all. This should be split into --help and --help-admin.
|
||
|
||
PLUGIN_DIRS = [ | ||
os.path.join(os.path.dirname(__file__), '..', 'plugins') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's plugins
for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Supposing the client should be open-source, we need some way to extend it to work with internal parts. This was the easiest way to achieve that. The client finds all python modules in a predefined place, loads the modules and later calls functions in them (run_hook
). The internal things would just implement the module, drop it into proper place and the client would just work.
This way the client class can help in other scripts. It allows user to instantiate BeanBag by just providing a URL or shortcut from settings. It handles the token transparently.
This patch adds commands for listing, showing, creating and updating RPMs. When showing info about particular RPM or updating, the database identifier is used. This could be replaced with NEVRA, but would require another dependency on something that can parse it. Unrelated to RPMs, this patch also modifies the way errors are presented to the user. This does not handle all possible failures. There are now also two methods that might simplify processing arguments from command line in that it is sufficient to declare them only once. The original manual way is still available to handle more complicated cases. JIRA: PDC-1023
The runner now only loads the plugins and all the actual work is implemented in plugins. There is a helper module with functions to simplify the plugins. It also contains some documentation on how to write the plugin.
I like this code structure, loose couple and easy to maintain. |
The plugins have two helper methods for adding commands. Anything added with `add_admin_command` will be hidden unless `--help-all` option is given. This is achieved by dropping the help from the command if the CLI argument was not used.
I have rebased the patches on master and restructured the commits so that they are meaningful. It is on pull request #125. So far, I don't have a clear idea on how to reasonably test the code. |
This client will have nicer user interface. The client allows loading
plugins from predefined directories so that implementing internal
extensions is possible.
TODO
--help
) and admin help (--help-all
).