[PATCH python-hglib] Add feature to allow hglib user to get call backs for prompts and output

[Barry Scott]

> On 18 Oct 2016, at 14:11, Yuya Nishihara <yuya at tcha.org> wrote:
> 
> On Tue, 18 Oct 2016 11:27:00 +0100, Barry Scott wrote:
>>> On 16 Oct 2016, at 15:36, Yuya Nishihara <yuya at tcha.org> wrote:
>>> On Thu, 06 Oct 2016 17:52:38 +0100, Barry A. Scott wrote:
>>>> # HG changeset patch
>>>> # User Barry A. Scott <barry at barrys-emacs.org>
>>>> # Date 1475772736 -3600
>>>> #      Thu Oct 06 17:52:16 2016 +0100
>>>> # Branch hglib-gui-features
>>>> # Node ID 1ac3819a61527836d47f7cd6a113b194c307ffeb
>>>> # Parent  efc527cc43d7394a5bd0deb1d29c4307592f7528
>>>> Add feature to allow hglib user to get call backs for prompts and output.
>>> 
>>>> The cb prefix was choosen to avoid matching a hg long option name.
>>> 
>>> That seems fine. merge() already has "cb" argument.
>>> 
>>>> -    def rawcommand(self, args, eh=None, prompt=None, input=None):
>>>> +    def rawcommand(self, args, eh=None, prompt=None, input=None, cbout=None,
>>>> +                   cberr=None):
>>>>        """
>>>>        args is the cmdline (usually built using util.cmdbuilder)
>>>> 
>>>> @@ -173,9 +174,29 @@
>>>> 
>>>>        input is used to reply to bulk data requests by the server
>>>>        It receives the max number of bytes to return
>>>> +
>>>> +        cbout is a function that will be called with the stdout data of the command
>>>> +        as it runs.
>>>> +
>>>> +        cberr is a function that will be called with the stderr data of the command
>>>> +        as it runs.
>>>>        """
>>> 
>>> Do they need to be separate callbacks? I think prompt() can be extended to
>>> take "err" value as an optional third argument.
>> 
>> There are 2 reasons to have the cbout and cberr call backs. For a push/pull that
>> does not prompt it provides the GUI with progress information clearly marked as
>> normal, cdout, and error, cberr. The output is also timely, no need to wait for the
>> command to complete.
> 
> In that case, it'd be nice if we have a generic callback interface like your
> another patch. Progress messages aren't limited to push/pull commands.

Oh I guess you are thinking of clone(), that will be long running and produces progress on the command line.
I can add that to the patch. Do you think I missed another that is long running, has progress and is silent in
hglib?

I do not think that the setprotocol pattern works for the command output.

Given only some commands can usefully return output and error text it seems better to pass in
the call backs if you want that information. It is then very clear which command the output and error
belongs to.

Many hglib commands want to process the output to return pythonic results from hglib to the user.
Other commands have no output and raise an exception with error text if they fail.
Both these seem to be fine already.

> 
>> When a prompt event happens I found that I cannot rely on figuring out what
>> the last prompt was without a timeline of calls to cdout and cderr.
> 
> or inspect the last lines of both out/err channels? Anyway it's unreliable to
> read the prompt line, so we'll need a better channel protocol in future.
> 
>> For example cdout gets the “user:” prompt but cderr gets the “password:”.
>> (Why is “password:” sent to stderr? Bug? Feature?)
> 
> That is considered a feature of hg, but isn't nice in command-server session.
> I made an extension to send more information over the pipe. It's just a hack.
> My current plan is to add an option to send prompt, progress, and status
> messages to a separate (e.g. 'C'-ontrol) channel.
> 
> https://bitbucket.org/tortoisehg/thg/src/3.9.2/tortoisehg/util/pipeui.py <https://bitbucket.org/tortoisehg/thg/src/3.9.2/tortoisehg/util/pipeui.py>
What I really want to see is a get-credentials call back, lIke subversion API has.

     username, password = cbgetcredentials( URL, realm, username=None )

Then I do not need to parse out for messages the URL, I can prompt the user once for
both username and password. I do this with this patch and a lot of extra logic in my GUI.

However is I can get something close to this patch committed I will be happy until a better
API can replace it.

Barry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20161018/c1437ff0/attachment.html>