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

login
register
mail settings
Submitter Barry A. Scott
Date Oct. 6, 2016, 4:52 p.m.
Message ID <1ac3819a61527836d47f.1475772758@varric.chelsea.private>
Download mbox | patch
Permalink /patch/16868/
State Changes Requested
Delegated to: Matt Mackall
Headers show

Comments

Barry A. Scott - Oct. 6, 2016, 4:52 p.m.
# HG changeset patch
# User Barry A. Scott <barry@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.

Both pull() and push() have had three new, optiomal, aguments added them.

cbprompt is used to reply to prompts by the server.
It receives the max number of bytes to return and the contents of stdout
received so far.

For pull() and push() there are prompts for username and password for
HTTP/HTTPS connections.

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.

The cb prefix was choosen to avoid matching a hg long option name.
timeless - Oct. 6, 2016, 7:03 p.m.
On Thu, Oct 6, 2016 at 12:52 PM, Barry A. Scott <barry@barrys-emacs.org> wrote:
> Both pull() and push() have had three new, optiomal, aguments added them.

optional ; arguments
Barry A. Scott - Oct. 7, 2016, 9:15 a.m.
On Thursday, 6 October 2016 15:03:32 BST timeless wrote:
> On Thu, Oct 6, 2016 at 12:52 PM, Barry A. Scott <barry@barrys-emacs.org> 
wrote:
> > Both pull() and push() have had three new, optiomal, aguments added them.
> 
> optional ; arguments

I'll fix the commit message once I have any more feedback.

Barry
Yuya Nishihara - Oct. 16, 2016, 2:36 p.m.
On Thu, 06 Oct 2016 17:52:38 +0100, Barry A. Scott wrote:
> # HG changeset patch
> # User Barry A. Scott <barry@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.
Barry A. Scott - Oct. 18, 2016, 10:27 a.m.
> On 16 Oct 2016, at 15:36, Yuya Nishihara <yuya@tcha.org> wrote:
> 
> On Thu, 06 Oct 2016 17:52:38 +0100, Barry A. Scott wrote:
>> # HG changeset patch
>> # User Barry A. Scott <barry@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.

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.

For example cdout gets the “user:” prompt but cderr gets the “password:”.
(Why is “password:” sent to stderr? Bug? Feature?)

My code can see that the last message was “password:” on cberr and know
that a password response is required.

I did not change the interface to prompt as it is already used elsewhere and
with the addition of cdout and cderr I can ignore its parameters.

Adding err to the prompt call may, or may not, be useful in other use cases.

Barry
Yuya Nishihara - Oct. 18, 2016, 1:11 p.m.
On Tue, 18 Oct 2016 11:27:00 +0100, Barry Scott wrote:
> > On 16 Oct 2016, at 15:36, Yuya Nishihara <yuya@tcha.org> wrote:
> > On Thu, 06 Oct 2016 17:52:38 +0100, Barry A. Scott wrote:
> >> # HG changeset patch
> >> # User Barry A. Scott <barry@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.

> 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
Barry A. Scott - Oct. 18, 2016, 2:15 p.m.
> On 18 Oct 2016, at 14:11, Yuya Nishihara <yuya@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@tcha.org> wrote:
>>> On Thu, 06 Oct 2016 17:52:38 +0100, Barry A. Scott wrote:
>>>> # HG changeset patch
>>>> # User Barry A. Scott <barry@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
Yuya Nishihara - Oct. 18, 2016, 3:29 p.m.
On Tue, 18 Oct 2016 15:15:35 +0100, Barry Scott wrote:
> 
> > On 18 Oct 2016, at 14:11, Yuya Nishihara <yuya@tcha.org> wrote:
> > 
> > On Tue, 18 Oct 2016 11:27:00 +0100, Barry Scott wrote:
> >> 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?

Maybe some of these:

archive, bundle, identify (of remote repo), incoming, outgoing,
summary (with remote=True), update (involving subrepo pull)

If we had verify(), it would also be slow.

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

Problem isn't that simple. You can run .log('outgoing()') for instance, which is
slow enough to show progress and sometimes needs a password prompt. That's why
I want to separate data and status messages at channel level.

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

Yeah, I want it.

For a temporary workaround, I think we can simply extend prompt().
Barry A. Scott - Oct. 18, 2016, 7:24 p.m.
On Wednesday, 19 October 2016 00:29:52 BST Yuya Nishihara wrote:
> On Tue, 18 Oct 2016 15:15:35 +0100, Barry Scott wrote:
> > > On 18 Oct 2016, at 14:11, Yuya Nishihara <yuya@tcha.org> wrote:
> > > 
> > > On Tue, 18 Oct 2016 11:27:00 +0100, Barry Scott wrote:
> > >> 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?
> 
> Maybe some of these:
> 
> archive, bundle, identify (of remote repo), incoming, outgoing,
> summary (with remote=True), update (involving subrepo pull)
> 
> If we had verify(), it would also be slow.
> 
> >  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.
> 
> Problem isn't that simple. You can run .log('outgoing()') for instance,
> which is slow enough to show progress and sometimes needs a password
> prompt. That's why I want to separate data and status messages at channel
> level.

I see why you want to set the call backs globally. I'll do that.

I think I can also have the solution for hglib.clone() and hglib.init().
I need to test more to be happy with those changes.

> > >> 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.
> Yeah, I want it.
> 
> For a temporary workaround, I think we can simply extend prompt().

What do you have in mind? I'm not seeing an easy win here.

Barry
Jordi Gutiérrez Hermoso - Oct. 18, 2016, 11:14 p.m.
On Thu, 2016-10-06 at 17:52 +0100, Barry A. Scott wrote:
> # HG changeset patch
> # User Barry A. Scott <barry@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.
> 
> Both pull() and push() have had three new, optiomal, aguments added them.

Is this really going to be cluttering the output of `hg help
pull/push`? The longer that gets, the less likely users are to read
it.

Indiscriminately growing new options on Mercurial commands, especially
for very niche uses, is very undesirable.
Jordi Gutiérrez Hermoso - Oct. 18, 2016, 11:15 p.m.
On Tue, 2016-10-18 at 19:14 -0400, Jordi Gutiérrez Hermoso wrote:
> On Thu, 2016-10-06 at 17:52 +0100, Barry A. Scott wrote:
> > # HG changeset patch
> > # User Barry A. Scott <barry@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.
> > 
> > Both pull() and push() have had three new, optiomal, aguments added them.
> 
> Is this really going to be cluttering the output of `hg help
> pull/push`? The longer that gets, the less likely users are to read
> it.

My bad, this is for hglib only. I understand any and all UI options
are welcome there.
Yuya Nishihara - Oct. 19, 2016, 2:54 p.m.
On Tue, 18 Oct 2016 20:24:28 +0100, Barry Scott wrote:
> I think I can also have the solution for hglib.clone() and hglib.init().
> I need to test more to be happy with those changes.

They could be switched to use the commandserver on hg 3.0+.

https://www.mercurial-scm.org/wiki/CommandServer#Known_issues

> > > >> 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.
> > Yeah, I want it.
> > 
> > For a temporary workaround, I think we can simply extend prompt().
> 
> What do you have in mind? I'm not seeing an easy win here.

Just pass both out and err to prompt():

  if prompt takes 3 args:
      reply = prompt(size, out.getvalue(), err.getvalue())
  else:
      reply = prompt(size, out.getvalue())

and check the last lines of them to guess which stream had a prompt.

Maybe we can strip the used out/err data to make the handling of multiple
prompts slightly better.

  prompt(size, out.getvalue()[p:], ...)
  p = out.pos

Patch

diff -r efc527cc43d7 -r 1ac3819a6152 hglib/client.py
--- a/hglib/client.py	Thu Oct 06 17:22:35 2016 +0100
+++ b/hglib/client.py	Thu Oct 06 17:52:16 2016 +0100
@@ -160,7 +160,8 @@ 
             else:
                 pass
 
-    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.
         """
         out, err = BytesIO(), BytesIO()
-        outchannels = {b('o') : out.write, b('e') : err.write}
+        outchannels = {}
+        if cbout is None:
+            outchannels[b('o')] = out.write
+        else:
+            def out_handler(data):
+                out.write(data)
+                cbout(data)
+            outchannels[b('o')] = out_handler
+        if cberr is None:
+            outchannels[b('e')] = err.write
+        else:
+            def err_handler(data):
+                err.write(data)
+                cberr(data)
+            outchannels[b('e')] = err_handler
 
         inchannels = {}
         if prompt is not None:
@@ -1198,7 +1219,8 @@ 
 
     def pull(self, source=None, rev=None, update=False, force=False,
              bookmark=None, branch=None, ssh=None, remotecmd=None,
-             insecure=False, tool=None):
+             insecure=False, tool=None, cbprompt=None, cbout=None,
+             cberr=None):
         """Pull changes from a remote repository.
 
         This finds all changes from the repository specified by source
@@ -1219,7 +1241,14 @@ 
         insecure - do not verify server certificate (ignoring
          web.cacerts config)
         tool - specify merge tool for rebase
-
+        cbprompt 
+        cbprompt is used to reply to prompts by the server
+         It receives the max number of bytes to return and the contents of stdout
+         received so far
+        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.
         """
         args = cmdbuilder(b('pull'), source, r=rev, u=update, f=force,
                           B=bookmark, b=branch, e=ssh,
@@ -1227,12 +1256,14 @@ 
                           t=tool)
 
         eh = util.reterrorhandler(args)
-        self.rawcommand(args, eh=eh)
+        self.rawcommand(args, eh=eh, prompt=cbprompt, cbout=cbout,
+                        cberr=cberr)
 
         return bool(eh)
 
     def push(self, dest=None, rev=None, force=False, bookmark=None, branch=None,
-             newbranch=False, ssh=None, remotecmd=None, insecure=False):
+             newbranch=False, ssh=None, remotecmd=None, insecure=False,
+             cbprompt=None, cbout=None, cberr=None):
         """Push changesets from this repository to the specified destination.
 
         This operation is symmetrical to pull: it is identical to a pull in the
@@ -1256,14 +1287,21 @@ 
         remotecmd - specify hg command to run on the remote side
         insecure - do not verify server certificate (ignoring
          web.cacerts config)
-
+        cbprompt is used to reply to prompts by the server
+         It receives the max number of bytes to return and the contents of stdout
+         received so far
+        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.
         """
         args = cmdbuilder(b('push'), dest, r=rev, f=force, B=bookmark, b=branch,
                           new_branch=newbranch, e=ssh, remotecmd=remotecmd,
                           insecure=insecure)
 
         eh = util.reterrorhandler(args)
-        self.rawcommand(args, eh=eh)
+        self.rawcommand(args, eh=eh, prompt=cbprompt, cbout=cbout,
+                        cberr=cberr)
 
         return bool(eh)