pulp/pulp-cli

Improve info on pulp-glue and adding version-constrain to option (on Contributing)

Closed this issue · 0 comments

Summary

When working on the drop of #831 Matthias clarified some history and practical info which would be useful in the Contributing section:

  • Introduction to pulp-glue and why it's important
  • How-to add option version-constrains (on pulp-glue)
  • Recommend pulp_option more generally for declaring options (over click.option)

Examples

pulp_option provides a superset of features over click.option. Since this project, as many others, grew organically, it is not quite used consistently in all places. To use things like needs_plugin, a pulp_option is absolutely necessary. I'm still on the fence whether we should recommend using it in (almost; --config is an exception for some reason as far as i remember) all places.

OK, sorry, needs_plugin does not work with click.option, but it still works when the layer below is raising the right exception (Hooray to stack unwinding exception handling!).

Declaring the need at the option level was what we were doing before realizing that pulp_glue had it's independent value as a standalone library. For the sake of the cli it almost does not matter where that exception is raised. But for uses of glue outside of the cli, it does.

I currently believe we should try as best as we can to move (or in your case, add) all version dependency in the glue library so all associated projects can benefit. This also makes the glue library the comprehensive guide to all known Pulp API subtleties.

The question of pulp_option over click.option is therefor in many cases one of best practice and least surprise. I think i'll vote for "use pulp_option" because this make pulpcore.cli.common.generic the library to the pulp-cli plugins and we have some control over subcommands that we loose when they use click.option directly.