You can accomplish most of this with the existing plugin system. You can't override existing commands, but you can easily create thin wrappers around them with your desired default args, and given the discussion around --no-aliases, it seems like this is actually a benefit. And plugins provide an easy way to add more intelligent handling of args, and also come with zero additional dev burden on core.
On Tue, Oct 27, 2015 at 3:24 AM, John Meinel <j...@arbash-meinel.com> wrote: > The one thing I don't think bash aliases give you is proper handling of > nested subcommands. Can you easily do "juju st" in a bash alias? or does it > have to become "juju-st" ? > I think the caveats around people aliasing their way out of clumsiness in > the tool is actually something to pay close attention to. It is very easy > to customize a tool around making it work great the way you want, but the > default experience for someone else is poor. (things like "juju status > --format=tabular" is one of those key places where we need to think > carefully about a great experience vs compatibility) > > It *is* a way to prototype "what if the commands acted this way" for us, > and to let users customize how they want to use the tool. But we need to be > rather proactive about turning our findings into actual changes to the > default behavior of the tool. > > Thinking about "--no-aliases" actually runs into the problem that it isn't > backwards compatible, either. You can't supply --no-aliases to old versions > of Juju, and you have to supply it to new ones in scripts. It feels like > ENV vars work a bit better here, as a script can set whatever ENV vars at > the beginning and then leave the rest of the script alone. (I'm pretty sure > that's why JUJU_CLI_VERSION=2 or whatever the exact syntax is, ended up as > an ENV var.) > > John > =:-> > > On Tue, Oct 27, 2015 at 7:43 AM, Nate Finch <nate.fi...@canonical.com> > wrote: > >> I don't think cross platform support of the config file format justifies >> the non-zero maintenance burden of the feature. Nor the non-zero >> maintenance burden of all the features that will inevitably follow after >> it, like the new --no-aliases flag, which is now cognitive overhead on >> every single command and every single script file. >> >> Also, I think Rick has it right - aliases mean users end up with >> different experiences of the product. This happened to me all the time with >> bzr plugins - first Martin would have to figure out what plugins I was >> using and what format my repo was in, and then he could help me figure out >> what I'd screwed up. ;) And people using aliases often forget that the >> command they type all the time is not actually built into the product. I >> can't tell you how often I've had someone tell me to 'git co <something>' >> (which is a common - but not universal - alias for git checkout). >> >> If you really want to use aliases, bash aliases work nearly identically, >> AFAICT, but with truly zero maintenance burden on core devs. By adding >> alias support to Juju, you're not only condoning aliases, you're >> encouraging their use, and I think that's a bad idea. If the UX of some of >> our commands suck, we should fix that. If our backwards compatibility >> policy is preventing us from fixing that, then at least we know the true >> cost of the policy - since most users in the wild are *not* going to be >> using any aliases. We should be using Juju in the same way as our >> less-experienced users, since all of our users will have to go through that >> period. (I'll ignore for the moment that quickstart has the exact same >> problem and is actually way more disruptive to the UX). >> >> -Nate >> >> >> On Mon, Oct 26, 2015 at 9:26 PM Tim Penhey <tim.pen...@canonical.com> >> wrote: >> >>> Hi Wayne, >>> >>> While I can see your point of view, I do disagree. >>> >>> While it may be of no benefit to you, it doesn't mean that others will >>> not find it useful. >>> >>> I believe it is useful to have one format to specify aliases, one that >>> doesn't depend on the shell that you use. >>> >>> The overhead in complexity isn't really that much, and with the >>> --no-alias option which is coming, it still provides a way to ensure >>> vanilla behaviour. >>> >>> >>> Tim >>> >>> On 27/10/15 04:03, Wayne Witzel wrote: >>> > After looking at this and the code more, I find myself very against >>> this >>> > feature. This adds code to core that is performing a tasks that most >>> > people already know is handled by their shell. Even our Windows users >>> > can install PowerShell and have aliases for commands. This adds no >>> > benefit to core, it adds more complexity, and attempts to perform a >>> task >>> > that is already well handled by the users shell. If anything, this itch >>> > could be scratched by adding some contrib documentation about some of >>> > your favourite and/or most used aliases. >>> > >>> > On Mon, Oct 26, 2015 at 10:51 AM, Wayne Witzel >>> > <wayne.wit...@canonical.com <mailto:wayne.wit...@canonical.com>> >>> wrote: >>> > >>> > What is the advantage of this over using a standard alias in my >>> > shell profile? >>> > >>> > On Fri, Oct 23, 2015 at 11:05 AM, Aaron Bentley >>> > <aaron.bent...@canonical.com <mailto:aaron.bent...@canonical.com>> >>> > wrote: >>> > >>> > bzr has a similar feature, but the problem with such a feature >>> > is that >>> > it can break scripts that expect the normal behaviour. That's >>> > why bzr >>> > provides a --no-aliases option, which all scripts calling bzr >>> > should use. >>> > >>> > The same applies to Juju. If "status" gets defaulted to >>> "status >>> > --format=tabular", most of our test scripts will break. This >>> isn't >>> > likely to happen on our test machines, but could easily happen >>> when >>> > devs run our test scripts. >>> > >>> > Could you please provide a similar --no-aliases option for >>> juju, so >>> > that we can ensure people don't break our scripts by specifying >>> > surprising defaults? >>> > >>> > Thanks, >>> > >>> > Aaron >>> > >>> > On 2015-10-23 12:12 AM, Tim Penhey 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 >>> > > >>> > > 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. >>> > > >>> > > The aliases files lives in JUJU_HOME, and is a simple text >>> file. >>> > > Each non blank line that doesn't start with a '#' is >>> considered to >>> > > be an alias. The format is expected to be: >>> > > >>> > > <command> = <command> [<args>...] >>> > > >>> > > So we can do things like: >>> > > >>> > > # stat is like two whole letters shorter... stat = status >>> > > --format=tabular >>> > > >>> > > # list tests list-environments = system environments >>> list-users = >>> > > user list >>> > > >>> > > and so on. >>> > > >>> > > Tim >>> > > >>> > >>> > -- >>> > Juju-dev mailing list >>> > Juju-dev@lists.ubuntu.com <mailto:Juju-dev@lists.ubuntu.com> >>> > Modify settings or unsubscribe at: >>> > https://lists.ubuntu.com/mailman/listinfo/juju-dev >>> > >>> > >>> > >>> > >>> > -- >>> > Wayne Witzel III >>> > wayne.wit...@canonical.com <mailto:wayne.wit...@canonical.com> >>> > >>> > >>> > >>> > >>> > -- >>> > Wayne Witzel III >>> > wayne.wit...@canonical.com <mailto:wayne.wit...@canonical.com> >>> > >>> > >>> >>> >>> -- >>> Juju-dev mailing list >>> Juju-dev@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju-dev >>> >> >> -- >> Juju-dev mailing list >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> >> > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
