Please make a python-glib release - is there a hold up?

[Barry Scott]

It has been a while since my patches where accepted, but there is no PyPi 
release with the changes yet.

Is there some process that I need to follow to get a python-glib release made?

Barry



___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: hglib uses distutils that is being deprecated

[Barry Scott]

On Monday, 7 November 2016 15:28:33 GMT Pierre-Yves David wrote:
> On 11/07/2016 03:23 PM, Barry Scott wrote:
> > So that I could use the recents improvements to python-hglib I built a
> > wheel.
> > 
> > I needed to patch setup.py to do this /distutils/setuputils/ so that I
> > could create the wheel with
> > 
> >  python3 setup.py sdist bdist_wheel
> > 
> > Then when I installed my wheel I go this:
> > 
> > $ pip3.5 install --upgrade  /home/barry/wc/hg/hglib/dist/
> > python_hglib-2.2_6_0f81ed8e147b_20161107-py3-none-any.whl
> > Processing /home/barry/wc/hg/hglib/dist/
> > python_hglib-2.2_6_0f81ed8e147b_20161107-py3-none-any.whl
> > Installing collected packages: python-hglib
> > 
> >   Found existing installation: python-hglib 2.0
> >   
> > DEPRECATION: Uninstalling a distutils installed project (python-hglib)
> > has
> > 
> > been deprecated and will be removed in a future version. This is due to
> > the
> > fact that uninstalling a distutils project will only partially uninstall
> > the project.
> > 
> > Uninstalling python-hglib-2.0:
> >   Successfully uninstalled python-hglib-2.0
> > 
> > Successfully installed python-hglib-2.2-6-0f81ed8e147b-20161107
> > 
> > Do you have a plan to update to setuputils?
> > 
> > I'm guessing that you want to use distutils to support verion old python
> > versions. If that is true then I'd guess that the setup.py would need to
> > do
> > something like:
> > 
> > try:
> >  from setuptools import setup
> > 
> > except ImportError:
> >  from distutils import setup
> 
> I know that Gregory Szorc is building wheel for Mercurial itself. We can
> probably use the same approache used by Mercurial in hglib (whatever
> this approach is). Can you send a patch for hglib?
> 

I don't think a wheel is created for mercurial. On Windows its a .exe and
on Fedoara the site-specific/mercurial is installed from the RPM.

Looking a bit closer at hglib I only see PyPI with a .tar.gz source file.
I guess you do nto use wheels at all and pip will do the setup.py install 
dance for the user.

I could patch to change from distutil to setuputil. But someone that knows
hglib's packaging strategy needs to speak to what is sensible to do.

Barry



Barry

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

hglib uses distutils that is being deprecated

[Barry Scott]

So that I could use the recents improvements to python-hglib I built a wheel.

I needed to patch setup.py to do this /distutils/setuputils/ so that I could
create the wheel with

 python3 setup.py sdist bdist_wheel

Then when I installed my wheel I go this:

$ pip3.5 install --upgrade  /home/barry/wc/hg/hglib/dist/
python_hglib-2.2_6_0f81ed8e147b_20161107-py3-none-any.whl 
Processing /home/barry/wc/hg/hglib/dist/
python_hglib-2.2_6_0f81ed8e147b_20161107-py3-none-any.whl
Installing collected packages: python-hglib
  Found existing installation: python-hglib 2.0
DEPRECATION: Uninstalling a distutils installed project (python-hglib) has 
been deprecated and will be removed in a future version. This is due to the 
fact that uninstalling a distutils project will only partially uninstall the 
project.
Uninstalling python-hglib-2.0:
  Successfully uninstalled python-hglib-2.0
Successfully installed python-hglib-2.2-6-0f81ed8e147b-20161107

Do you have a plan to update to setuputils?

I'm guessing that you want to use distutils to support verion old python 
versions. If that is true then I'd guess that the setup.py would need to do
something like:

try:
 from setuptools import setup
except ImportError:
 from distutils import setup

Barry

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH python-hglib v2] Add feature to allow hglib user to get call backs for prompts, output

[Barry Scott]

FYI: My code that uses this patch is in SCM Workbench.

Here is the code I use for init() and clone():

https://github.com/barry-scott/scm-workbench/blob/master/Source/Hg/
wb_hg_project.py#L65

Here is the object that handles the call back interface and map into my GUI's 
world:

https://github.com/barry-scott/scm-workbench/blob/master/Source/Hg/
wb_hg_project.py#L448

Barry

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH python-hglib v2] Add feature to allow hglib user to get call backs for prompts, output

[Barry Scott]

On Monday, 24 October 2016 22:30:08 BST Yuya Nishihara wrote:
> On Mon, 24 Oct 2016 11:04:39 +0100, Barry Scott wrote:
> > > So this patch contains 3 different things. Can you send them as separate
> > > patches?
> > > 
> > > - add callbacks
> > > - change clone() behavior (which seems wrong)
> > > - add init()
> > 
> > Yes and no. Both clone and init cannot be used with the call backs with
> > these changes.
> > 
> > I can package as 3 patches that build on each other. But in my mind these
> > are linked.
> > 
> > I will do as you advise, please confirm 3 patches required.
> 
> https://www.mercurial-scm.org/wiki/ContributingChanges#Submission_checklist
> 
> "6. patch does just one thing (if you need a bullet list, split your patch)"
> 
> I would split clone/init changes since they solve separate issues on top of
> the new callback API.
> 
> > >> +def setcbprompt(self, 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.
> > >> +
> > >> +Call with None to stop getting call backs.
> > >> +
> > >> +cbprompt is never called from merge() or import_()
> > >> +which already handle the prompt.
> > >> +"""
> > >> +self._cbprompt = cbprompt
> > > 
> > > Nit: The "cb" prefix doesn't make sense here because there's little
> > > possibility of name conflicts.
> > 
> > True but it is descriptive.
> 
> Hmm, but it introduces new naming style, right? I have no strong opinion
> about this, but "prompt" seems just fine because we already have one.

prompt is not part of the public API.

> 
> > > And I think your setprotocoltrace() covers setcbout/err. Do we still
> > > need them?> 
> > They solve two distinct problems.
> > 
> > protocol tracing provides a way to see the low level, almost unprocessed
> > messages between client and server. Its purpose is to allow inspection
> > and debugging of the protocol.
> > 
> > cbout and cderr provide a user of hglib with the post processed output and
> > error information.
> > 
> > In production my GUI will use cdout and cderr often, but never protocol
> > trace. But when I cannot figure out what is happening I turn on protocol
> > trace to get an insight into how hglib works. That is, for example, how I
> > found that password: is sent on the ‘e’ channel.
> > 
> > Conclusion yes we need both.
> 
> Okay, I don't think they are required, but I agree they are semantically
> different from setprotocoltrace().
> 
> Another option is to provide an interface to set a single callback object
> that handles o/e/I/L channels altogether, so we could provide a helper class
> to translate o+L and e+L sequences to .prompt() and .password()
> respectively.

I've assumed that its better to leave the hglib patch simple.

As we talked about before a getcredentials call back would be great.
But That needs hg itself to change. I sugest that we stay with this API
until that is possible.

> 
> TortoiseHg handles user interaction in that way:
> https://bitbucket.org/tortoisehg/thg/src/3.9.2/tortoisehg/hgqt/cmdcore.py#cm
> dcore.py-44
> 
> BTW, is hglib usable in GUI? I think its synchronous I/O will behave pretty
> bad in GUI environment.

With these patches its usable :-)

I run any long running hg operation in a background thread.

> > >> def clone(self, source=b('.'), dest=None, branch=None,
> > >> updaterev=None,
> > >> 
> > >> -  revrange=None):
> > >> +  revrange=None, pull=False, uncompressed=False, ssh=None,
> > >> 
> > >> +  remotecmd=None, insecure=False, encoding=None, 
configs=None):
> > >> """
> > >> Create a copy of an existing repository specified by source in
> > >> a new
> > >> directory dest.
> > >> 
> > >> @@ -536,9 +584,30 @@
> > >> 
> > >> revrange - include the specified changeset
> > >> """
> > >> args = cmdbuilder(b('clone'), source, dest, b=branch,
> > >> 
> > >> -  u=updaterev, r=revrange)
> > >> +  u=updaterev, r=revrange, pull=p

Re: [PATCH python-hglib] Add the abilty to trace the protocol between the client and server

[Barry Scott]

> On 16 Oct 2016, at 15:50, Yuya Nishihara  wrote:
> 
> On Thu, 06 Oct 2016 18:04:47 +0100, Barry A. Scott wrote:
>> # HG changeset patch
>> # User Barry A. Scott 
>> # Date 1475770955 -3600
>> #  Thu Oct 06 17:22:35 2016 +0100
>> # Branch hglib-protocol-trace
>> # Node ID efc527cc43d7394a5bd0deb1d29c4307592f7528
>> # Parent  6f15cb7cc9cb4427f35c60080f85dbf4ca5abd10
>> Add the abilty to trace the protocol between the client and server.
>> This is useful when debugging issues with driving hg via hglib
>> where output and error messages can be lost.
>> 
>> call setprotocoltrace with the name of a trace function or None.
>> If the trace function is None no tracing is done.
>> The trace function is called with the channel and its data.
> 
> This generally looks good to me. Can you update the commit message and
> coding style?
> 
> https://www.mercurial-scm.org/wiki/ContributingChanges 
> 
> 

No problem. I have read that link and the coding style and thought that I coded 
in the
required style. Can you point to the drop off please?

>> diff -r 6f15cb7cc9cb -r efc527cc43d7 hglib/client.py
>> --- a/hglib/client.pyMon Jul 18 23:40:45 2016 -0500
>> +++ b/hglib/client.pyThu Oct 06 17:22:35 2016 +0100
>> @@ -62,6 +62,15 @@
>> if connect:
>> self.open()
>> 
>> +self._protocoltracefn = None
>> +
>> +def setprotocoltrace( self, tracefn=None ):
>> +"""
>> +if tracefn is None no trace calls will be made.
>> +Otherwise tracefn is call as tracefn( channel, data )
>> +"""
>> +self._protocoltracefn = tracefn
>> +
>> def __enter__(self):
>> if self.server is None:
>> self.open()
>> @@ -119,6 +128,7 @@
>> 
>> def runcommand(self, args, inchannels, outchannels):
>> def writeblock(data):
>> +if self._protocoltracefn is not None: self._protocoltracefn( 
>> b'i', data )
> 
> Using a fake channel name seems a bit unfortunate. I slightly prefer b'' or
> None.s

I reasoned that given:

stdout is ‘o’
stderr is ‘e’

Clearly if there was an actual channel id for stdin the code would use ‘i’.

I could use b’’ or None, but that would just mean I need more code in the 
callers code mapping
None or b’’ into ‘i’ for printing.

It seemed better to have an obvious identifier.

Barry



___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

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

[Barry Scott]

> On 16 Oct 2016, at 15:36, Yuya Nishihara  wrote:
> 
> On Thu, 06 Oct 2016 17:52:38 +0100, Barry A. Scott wrote:
>> # HG changeset patch
>> # User Barry A. Scott 
>> # 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

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

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

[Barry Scott]

On Thursday, 6 October 2016 15:03:32 BST timeless wrote:
> On Thu, Oct 6, 2016 at 12:52 PM, Barry A. Scott  
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

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel