On 23/10/15 21:28, roger peppe wrote: > On 23 October 2015 at 05:12, Tim Penhey <[email protected]> wrote: >> Hi folks, >> >> I scratched a personal itch yesterday and added the ability for users to >> specify their own aliases for juju commands. >> >> There are two primary use cases that I was trying to address. >> >> Firstly, the ability to specify default flags for commands: >> status = status --format=tabular > > This sounds useful, thanks. Presumably additional arguments are > just tacked onto the end?
No... not exactly, an infix replacement. For example, lets say I had the above status alias. If I really wanted json output I'd go: juju status --format=json The alias mechanism turns this into: juju status --format=tabular --format=json And the default flag behaviour is for the last to win, so format is set to json. >> I could never remember the right environment variable to set to get >> tabular by default. >> >> The second was to allow quicker iteration around playing with new CLI >> structure. As most people are aware, the 2.0 CLI is going to be >> somewhat different to the current one, and I thought it would be good to >> provide a way in which we could "test drive" the new CLI with the >> existing codebase without having to actually code anything. > > Unless the new CLI is non-hierarchical I'm thinking that may > not work unless you can specify multi-level aliases; > For example: > > model destroy = environment destroy > > which might be a little harder. Exactly. We tried with hierarchical sub-menus, but the experiment is considered a successful way to not do it :-) Juju 2.0 will transition back to a flat command namespace with a predictable set of <verb>-<object> commands along with another set that make more sense by themselves, i.e. "deploy", "relate". Tim -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
