Defining extension "subcommands"

[Angel Ezquerra]

On Sat, Apr 5, 2014 at 2:33 AM, Augie Fackler <raf at durin42.com> wrote:
>
> On Mar 31, 2014, at 4:46 PM, Angel Ezquerra <angel.ezquerra at gmail.com> wrote:
>
>> On Mon, Mar 31, 2014 at 8:33 PM, Matt Mackall <mpm at selenic.com> wrote:
>>> On Mon, 2014-03-31 at 12:53 +0200, Angel Ezquerra wrote:
>>>> Hi,
>>>>
>>>> is it possible to create an extension that has a command with several
>>>> "subcommands"?
>>>
>>> It is, but it's discouraged. The bisect extension used to work this way,
>>> for instance, but I hid that when I moved it to core.
>>
>> I googled for a solution before asking here and I found an old version
>> of the bisect extension help text that did indeed have subcommands.
>> Then I checked the current bisect command and I saw that it no longer
>> uses them.
>>
>> Would you mind giving me some details on why you think it is not a
>> good idea to use subcommands? Each of the commands on my extension has
>> its own set of parameters. It feels a bit off to use one of the
>> parameters to choose the action that is going to be performed... I can
>> of course prepend each command with "tf" but I don't like that too
>> much either...
>
> I can't speak to it generally, but for the "integration with another VCS" case I've found it's a little better to just make "hg pull" do the right thing and to encode any necessary metadata into the phony URL you pull from. hgsubversion does have an 'svn' command where we hang some random subsubcommands, but by now the only ones there *I* even remember are "hg svn info" (which emulates "svn info") and "hg svn rebuildmeta", both of which are seldom-used. In fact, I can see an argument for "hg svn info" being "hg summary --svn", but I'm not sure it's worth bothering.
>

Thank you Augie, that is very good advice that I'll try to follow :-D

I've been looking at the way hggit and hgsubversion work and the way
they work is somewhat similar to what I've done. However your code is
_way_ cleaner than mine :-)

My hgtf extension started as a quick and dirty stand alone python
script. I only converted into an actual hg extension after the fact (I
just added a few commands that end up calling the original stand-alone
tool, kind of like what Martin was suggesting, but in reverse). I did
it this way to try to just use mercurial's command line interface,
avoiding accessing any mercurial internals. However I now think it
would be best to wrap mercurial's pull/outgoing/push commands as you
suggest, even if I have to access mercurial's internals a bit.

Thanks for your advice,

Angel