Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

2015-10-27 Thread John Meinel 
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 
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 ' (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 
> 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
>> > > 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
>> > >
>> > 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.
>> >
>> >

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

2015-10-27 Thread Cory Johns 
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  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 
> 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 '
>> (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 
>> 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
>>> >

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

2015-10-27 Thread Tim Penhey 
I can't help but draw parallels to the plugin system.

There was considerable resistance to adding the ideas of plugins to
Juju. It was added complexity that no one needed and could be done
simply using existing executable scripts, like juju-foo.

Tim

On 28/10/15 07:33, Cory Johns wrote:
> 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.


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

2015-10-27 Thread Aaron Bentley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thank you!

Aaron

On 2015-10-26 09:22 PM, Tim Penhey wrote:
> On 24/10/15 04:05, Aaron Bentley 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?
> 
> http://reviews.vapour.ws/r/2999/
> 
> done
> 
> Tim
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWL9XGAAoJEK84cMOcf+9hLTgH/A7/kn27kdD6X7u2YxzX8cuW
27DjAktjFT6Jg2yi21KFl34FsOrTJc88AJXykPyX5lk69x9v/1mSV3ObO2U45Mxj
UiqS19xhUzZGJH01slZusyM9CFWEoYvtAOxlSXSgn33TrimwY6Yd3tPIS5WUw65t
bsl5ay1I4TvHB9dsbfHRKFjbW381DEgAnVT4j8Gs5JgyqabwFImPAQMkBHzRsEiz
qTzgKXDPpShN23wLxpZwgYQIuY/iYHQZvHLKIkXBzIspzgPD4WkbIvEj5xV58A3Z
+Tmj9mBtOuVJrlxd+XKO5bXxGd47yi3/hfGIY8WtZZ6KPojTJVgHJ4jbZZQIrZw=
=s4eS
-END PGP SIGNATURE-

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

2015-10-27 Thread Nate Finch 
You're not selling me on this ;)

On Tue, Oct 27, 2015, 4:01 PM Tim Penhey  wrote:

> I can't help but draw parallels to the plugin system.
>
> There was considerable resistance to adding the ideas of plugins to
> Juju. It was added complexity that no one needed and could be done
> simply using existing executable scripts, like juju-foo.
>
> Tim
>
> On 28/10/15 07:33, Cory Johns wrote:
> > 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.
>
>
> --
> 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

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

2015-10-26 Thread Tim Penhey 
On 24/10/15 04:05, Aaron Bentley 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?

http://reviews.vapour.ws/r/2999/

done

Tim

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

2015-10-26 Thread Tim Penhey 
On 24/10/15 00:40, Rick Harding wrote:
> 
> 
> On Fri, Oct 23, 2015 at 12:12 AM Tim Penhey  > wrote:
> 
> Hi folks,
> 
> 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.
> 
> 
> This is very cool Tim. I would like to raise a word of caution though.
> When folks get aliasing too much to work around pain points of the
> experience it makes it easy to hide the pain and not raise it up and
> deal with it.  My one hesitation here is that we need to make sure that
> these are small and that if we find common ones that we bring them up as
> things that should be fixed in the cli vs "just use the following
> aliases" in reply to folks frustrations. 
> 
> In particular, with the 2.0 cli experiments, it'd be helpful if there
> was some method that everyone could be using a shared experience so that
> we were getting real testing of a common plan for a 2.0 cli vs everyone
> building their own 2.0 as they go. 
> 
> Not to be negative on the cool handy feature, but something to think
> about as folks go adding their aliases. 

I agree that we should take care when talking more about aliases.

If we find that there are a set that people generally like using, we
should consider making it more a core part of Juju, and not rely on aliases.

Aliases are useful for some people for some tasks. I don't think they
will be used by everyone, nor or are they supposed to be.

Tim


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

2015-10-26 Thread Tim Penhey 
On 23/10/15 21:28, roger peppe wrote:
> On 23 October 2015 at 05:12, 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
> 
> 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 - commands along with another set that
make more sense by themselves, i.e. "deploy", "relate".

Tim

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

2015-10-26 Thread Tim Penhey 
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
> > 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
> >
> 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:
> >
> >  =  [...]
> >
> > 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 
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> 
> 
> 
> 
> -- 
> Wayne Witzel III
> wayne.wit...@canonical.com 
> 
> 
> 
> 
> -- 
> Wayne Witzel III
> 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

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

2015-10-26 Thread Wayne Witzel 
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  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:
> >
> >  =  [...]
> >
> > 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
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>



-- 
Wayne Witzel III
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

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

2015-10-26 Thread Wayne Witzel 
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 
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> 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:
>> >
>> >  =  [...]
>> >
>> > 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
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
>
>
> --
> Wayne Witzel III
> wayne.wit...@canonical.com
>



-- 
Wayne Witzel III
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

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

2015-10-23 Thread Aaron Bentley 
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:
> 
>  =  [...]
> 
> 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
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

2015-10-23 Thread Dimiter Naydenov 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Awesome!! \o/

As a big fan of aliases (bash, git, etc.) I'd start using this right
away with juju now! :)

Thanks Tim!

Dimiter

On 23.10.2015 07:12, 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:
> 
>  =  [...]
> 
> 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
> 


- -- 
Dimiter Naydenov 
Juju Core Sapphire team 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWKeZDAAoJENzxV2TbLzHwOuMH/Rt5OqT29cGheVBNGraC0guR
qYSyS8nqsSKb7gizmu9HrbJeQjpQfv+Dskc97yOXlxsQbhfBrFGHkkHl15jsKHBh
XCx531/olNhs8Y9uqfI31SjMqRW4U0wylF4sVfMOpIsrTlJcuU7EQ8meYj0ObR7T
RWv9Rg6pg6b6fQ5tylVV+8LjE6YyRUr+V+8rQp/PLwVrACJQqVyi+tL5UQKd53vj
pgCqEbRJ/wN8fcQP7Pf6jh+FC84xecwmAd9Zc/toHXHh0ZYSKl022h0pPff/1XoB
JQqGyH4SS7XAR3T6jiy6ub7wYCe0LgkPtl13nbcrWR1YYZK1pJxtH+kdkwfYaXk=
=UrrP
-END PGP SIGNATURE-

-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New feature for 1.26 (master), $(JUJU_HOME)/aliases

2015-10-23 Thread roger peppe 
On 23 October 2015 at 05:12, 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

This sounds useful, thanks. Presumably additional arguments are
just tacked onto the end?

> 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.

While I'm on the subject of hierarchical CLIs, I often have difficulty
remembering where a given command is buried. "juju commands | grep"
was often a decent solution but doesn't work when the command
I'm looking for is buried two levels deep. Any chance of something like
"juju commands --all" to show all commands, even those two or more
levels down?

  cheers,
rog.

>
> 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:
>
>  =  [...]
>
> 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
> 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