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

[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

[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

[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

[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

[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

[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