Re: [PATCH evolve-ext v2] py3: broad pass for python3 compatibility
> This patch don't apply anymore :-/ It is also very invasive and will be > painful for all other contributors. It might be because I created the patch on top of `stable` instead of some other head? To be precise it was applied on top of the 9.0 release since that was the latest on the stable branch last week. > Do you think we could get to a point where no manual tweaking is needed > ? (could be simply adding dedicated comment to line that need to be > skipped). If we have a script only approach we could use the > format-source extensions for that. I already mentioned the steps to reproduce the patch, but there's one more step now: 1. Run `byteify-strings` with `--dictiter` 2. Remove the added `b` prefix where `exthelper.addattr` is used (there should be only 2 places with it in `obsdiscovery.py`). 3. In `templatekw.py` we wrap some functions and re-feed them to `templatekeyword`. Down the callstack it tries to encode the docstring, but it had already been encoded once, so you'll notice 2 more manual edits to decode the docstring back into its original form. To get to a script-only approach, you can submit the 2 changes from step 3 as a separate changeset, and then somehow modify `byteify-strings` so that step 2 isn't necessary... a simple approach would be to add some support for a line-end comment like the `#noqa` that some linters support... so say you add `#nobytestr` at the end of the 2 appropriate lines in `obsdiscovery.py` so that the script skips them. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH evolve-ext v2] py3: broad pass for python3 compatibility
> I'm curious to hear what Ludovic thinks, but I'm doubtful that saves > other contributors more time than it costs for Ludovic, so it's a net > negative. > > I assume you know that Python 2's end of life is Jan 1 2020, so this > is getting urgent. I don't know about others, but my team will need to > have Mercurial and extensions on Python 3 by then. At this point it's not too costly for me to update the patch (although it's a bit annoying), especially since I'm not even running any tests yet at this point: I just need a py3 mercurial that doesn't crash when evolve is enabled, and seems to run ok for pull/push. However, I would indeed prefer if someone from Octobus was to take it away from me and deal with it ASAP. It's blocking several new features for sourcehut, and, indeed, py3 EOL is approaching fast and both Drew (lead dev on sourcehut) and Alpine (the distro on which sourcehut runs) have aggressive timelines to completely remove any trace of py2 before that date. Plus, if someone from Octobus was to take this, it could also be part of a broader "kickstart py3 support" task that would include setting up py3 builds on the CI, and other related tasks. Cheers! ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH evolve-ext v2] py3: broad pass for python3 compatibility
On Sun, Jun 30, 2019 at 10:42 PM Ludovic Chabant
wrote:
> # HG changeset patch
> # User Ludovic Chabant
> # Date 1561959530 0
> # Mon Jul 01 05:38:50 2019 +
> # Branch stable
> # Node ID 89e3ab4dcbc56ee72ce1d4d17527337e01d99467
> # Parent 90daf413dfc7a7e4762e6445f05c52b123c6188f
> py3: broad pass for python3 compatibility
>
> - ran mercurial's bytify-strings script
> - excluded some places where we use strings to pass to setattr()
> - re-decode some template funcions' docstrings that were previously encoded
> (probably by the hgloader?)
>
> diff --git a/hgext3rd/evolve/__init__.py b/hgext3rd/evolve/__init__.py
> --- a/hgext3rd/evolve/__init__.py
> +++ b/hgext3rd/evolve/__init__.py
> -@eh.wrapfunction(mercurial.cmdutil, 'tryimportone')
> +@eh.wrapfunction(mercurial.cmdutil, b'tryimportone')
> def tryimportone(orig, ui, repo, hunk, parents, opts, *args, **kwargs):
> -expected = {'node': None}
> -if not util.safehasattr(hunk, 'get'): # hg < 4.6
> +expected = {b'node': None}
> +if not util.safehasattr(hunk, b'get'): # hg < 4.6
> oldextract = patch.extract
>
> def extract(*args, **kwargs):
> @@ -845,12 +845,12 @@
> _getnodefrompatch(hunk, expected)
> ret = orig(ui, repo, hunk, parents, opts, *args, **kwargs)
> created = ret[1]
> -if (opts['obsolete'] and None not in (created, expected['node'])
> -and created != expected['node']):
> -tr = repo.transaction('import-obs')
> +if (opts[b'obsolete'] and None not in (created, expected[b'node'])
>
Should opts[x], opts.get(x), etc really use bytes? They usually get passed
as **opts, which means their keys are str, I think.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH evolve-ext v2] py3: broad pass for python3 compatibility
> > Should opts[x], opts.get(x), etc really use bytes? They usually get passed as > **opts, which means their keys are str, I think. > Sounds OK to me -- there's probably a whole bunch of places that might need to be excluded. It might be worth exploring doing the opposite approach, i.e. manually adding byte strings until things work. ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH evolve-ext v2] py3: broad pass for python3 compatibility
On Thu, Jul 4, 2019, 16:59 Ludovic Chabant wrote: > > > > > Should opts[x], opts.get(x), etc really use bytes? They usually get > passed as **opts, which means their keys are str, I think. > > > > Sounds OK to me -- there's probably a whole bunch of places that might > need to be excluded. It might be worth exploring doing the opposite > approach, i.e. manually adding byte strings until things work. > I've spent a few hours on that and it feels like I'm making good progress. I'll spend a few more when I get back from vacation (Monday). I'll let you know how it goes. > ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
Re: [PATCH evolve-ext v2] py3: broad pass for python3 compatibility
For those following at home: * We now have a evolve + py3 build https://ci.octobus.net/job/EvolvePy3/ * Martin's patch that apply most of the py3 compatibility changes have been merged (and should be in the next evolve version). * Raphaël is now looking into using format-source + the `byteify-strings.py` script to produce the last necessary patch. There are a couple of reasons why we would like to take that route. First, code-formatting is becoming an important topic, we need features like format-source to work smoothly. Having more dog fooding in repositories closer to core-developer is important. Second, there will be more important extensions to convert (eg: hg-git, hg-subversion, etc). Investing in making the tooling (both format-source and byteify-string) simpler to use should help with their migrations. On 7/2/19 4:58 PM, Ludovic Chabant wrote: I'm curious to hear what Ludovic thinks, but I'm doubtful that saves other contributors more time than it costs for Ludovic, so it's a net negative. I assume you know that Python 2's end of life is Jan 1 2020, so this is getting urgent. I don't know about others, but my team will need to have Mercurial and extensions on Python 3 by then. At this point it's not too costly for me to update the patch (although it's a bit annoying), especially since I'm not even running any tests yet at this point: I just need a py3 mercurial that doesn't crash when evolve is enabled, and seems to run ok for pull/push. However, I would indeed prefer if someone from Octobus was to take it away from me and deal with it ASAP. It's blocking several new features for sourcehut, and, indeed, py3 EOL is approaching fast and both Drew (lead dev on sourcehut) and Alpine (the distro on which sourcehut runs) have aggressive timelines to completely remove any trace of py2 before that date. Plus, if someone from Octobus was to take this, it could also be part of a broader "kickstart py3 support" task that would include setting up py3 builds on the CI, and other related tasks. Cheers! -- Pierre-Yves David ___ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
