[PATCH RFC] shellext: automatically add shell scripts as new commands

Matt Mackall mpm at selenic.com
Mon Jan 9 15:36:49 CST 2012


On Mon, 2012-01-09 at 22:09 +0100, Martin Geisler wrote:
> Matt Mackall <mpm at selenic.com> writes:
> 
> > On Sat, 2012-01-07 at 18:56 +0100, Martin Geisler wrote:
> >> # HG changeset patch
> >> # User Martin Geisler <mg at aragost.com>
> >> # Date 1325959011 -3600
> >> # Node ID 8c34fa2adf476a1e07512207fb18866e7908cf58
> >> # Parent  3fe39d6d2bd8331932df063d272fff8af327881c
> >> shellext: automatically add shell scripts as new commands
> >> 
> >> People sometimes note that Mercurial extensions must be written in
> >> Python, whereas extensions for Git can be written in any language.
> >> Some people see this as an advantage for Git. This extension lets you
> >> do the same for Mercurial.
> >> 
> >> The only required change to core Mercurial is loading the extensions
> >> before checking for shell aliases -- this is so that the extension
> >> has a chance to register the new shell aliases.
> >
> > Interesting. Some musings:
> >
> > - Is this any different from aliases.foo = !somecommand?
> >
> > Not yet?
> 
> It's 99% the same: the only difference is that I removed one '--' from
> the arguments so that one can do
> 
>   hg foo -- --config
> 
> to execute
> 
>   foo.sh --config
> 
> With a normal shell alias that uses $@, you get
> 
>   foo.sh -- --config
> 
> > - Do we search for other extensions in ~/.hgext?
> >
> > Looks like no.
> 
> Ah, extensions... I like your idea of ~/.hgshellext a lot, that's a much
> better name for the functionality in this little hack.
> 
> > - Should this be built-in functionality?
> >
> > Probably, if the aim is to making dropping things in trivial.
> >
> > - Should we automatically enable everything in .hgext?
> >
> > Probably, for consistency. But then 'hg showconfig --debug' no longer
> > completely explains where extensions are coming from. Alternately, the
> > name needs to be .hgshellext or something to make it clear that it's
> > not for normal extensions.
> >
> > - How do we ship a shell extension in a way that a user can enable?
> >
> > Should --config extensions.shellfoo= find $HGLIB/shellfoo.sh?
> 
> Hmm, good questions :) I did not think of it as enabling *extensions*,
> more like enabling *commands*. So this was not so much about making
> shell scripts equivalent to Python extensions, but more a way to easily
> add a new command to Mercurial.
> 
> But it's cool if we can generalize this.
> 
> > - How do we make these things work with the help engine?
> >
> > By wrapping some RST in a specially-formatted comment block?
> 
> Maybe better by looking for a foo.rst file when we have a
> foo.something-else file?

Mercurial extensions can be single .py files, why not these? Having two
files is just an invitation to have install errors and mismatched help.

> > - What happens if someone shadows a built-in?
> >
> > - Can we do anything to facilitate argument parsing?
> >
> > It'd be extremely helpful to do some option parsing/validation like
> > fancyopts does and making sure we have the right number of args.
> 
> You mean that the script can declare its arguments and we'll validate
> them before starting the script? I had expected the script to do that
> itself.

Oh sure, it's possible to do it that way. But given the tedium of doing
shell programming right, we can already expect the quality of
implementation of these shell extensions to be... embarrassing. Doing
anything approaching the robustness of fancyopts in sh (or cmd.exe!) is
well beyond the abilities of the average shell programmer.

> > - How does the created environment compare to the generic pre- and post-
> > command hooks?
> >
> > It should be the same (or richer). We'll need to be able to find the
> > current hg executable, for starters.
> 
> Sounds very reasonable.
> 
> > - What about Windows?
> >
> > Should we look for .cmd scripts too?
> >
> > - What if I want to write an extension in Python that's not a normal
> > Mercurial extension?
> >
> > Ok, probably don't care about that.
> 
> Agreed.
> 


-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list