Python 2 removal and thg packaging status

[Raphaël Gomès]

Hi there,

It's been a few months, and Python 3 Windows support is in much better 
shape than it used to. The CI is still flaky, but at least we've got a 
decent coverage of core Mercurial.

Greg, what's the status regarding thg packaging? Next release cycle 
(6.1) will remove Python 3 support and we need thg to get up to speed by 
then.

On 4/15/21 12:08 AM, Gregory Szorc wrote:
> My plan of attack was to implement support for packaging in PyOxidizer 
> and have thg (and Mercurial) use this functionality (with or without 
> the traditional PyOxidizer-building-the-binary approach). However, 
> I've been sidetracked by various things. Ugh, COVID.
>
> I'll try to take a look at what features I still need to implement in 
> PyOxidizer to proceed with this plan in the next week or so.
>
> On Mon, Apr 12, 2021 at 11:52 AM Augie Fackler <raf at durin42.com 
> <mailto:raf at durin42.com>> wrote:
>
>
>
>>     On Apr 3, 2021, at 6:34 PM, Matt Harbison <mharbison72 at gmail.com
>>     <mailto:mharbison72 at gmail.com>> wrote:
>>
>>     On Sat, Apr 3, 2021 at 12:18 PM Raphaël Gomès
>>     <raphael.gomes at octobus.net <mailto:raphael.gomes at octobus.net>> wrote:
>>>
>>>     Hello all,
>>>
>>>     As you all know, Mercurial's codebase is still burdened by Python 2
>>>     support. Patches still
>>>     need to be adapted for backwards compat, some Python niceties still
>>>     cannot be used,
>>>     and the Heptapod CI which is used on a near majority of the
>>>     patches we
>>>     collectively land
>>>     is still putting in double shifts as well.
>>>
>>>     At the last (virtual) sprint, everybody present agreed that the
>>>     time had
>>>     long passed to drop
>>>     Python 2 support, but that it couldn't be done until
>>>     TortoiseHg's Python
>>>     3 Windows packaging
>>>     story was straightened out. Where are we standing on the matter?
>>>     Are we
>>>     close?
>>
>>     I've been making progress on adding type hints and fixing issues in
>>     the TortoiseHg code.  The good news is there are ~13 files left that
>>     are excluded.  The bad news is I know for a fact that some of the
>>     *included* files have type mismatches that pytype isn't detecting.
>>     Some of this could be helped by moving to py3. Â (e.g. pytype seems to
>>     not recognize `foo[b'bar']` as calling `__getitem__()` on an object,
>>     and treats it as returning Any, even when there's type info on the
>>     function. Subclassing typing.Mapping seems to help in some cases, but
>>     classes like `config.config` and `localrepo.localrepository` really
>>     can't subclass that because they have functions like `items()` with a
>>     signature that differs from the base class.  It also seems to
>>     struggle
>>     with @annotations.) Â IDK for sure how far I am through adding type
>>     hints, because it's so non linear by nature.  If I had to guess,
>>     maybe
>>     50%?
>>
>>     Stepping back from the thg work, there's also core work that still
>>     needs to be done.  I just ran the tests locally and got 19 failures
>>     (excluding fixes I'm about the send), and skipping 114 which are
>>     mostly never going to work on Windows because of symlink, executable
>>     bit, casefolding, etc.  Some of those skips are test-convert-* other
>>     than git, so I assume that's a mess.  I don't care about that, but
>>     somebody might.  Of the failures, 4 are test-gendoc-*, so IDK how
>>     important those are.  Some of the other failures are... concerning.
>>     But they may have simple fixes.  There are runtime issues that
>>     are not
>>     detected by tests, such as
>>     https://bz.mercurial-scm.org/show_bug.cgi?id=6446
>>     <https://bz.mercurial-scm.org/show_bug.cgi?id=6446>and getting no
>>     output for commands that spin up a pager. Â (I *think* the latter is
>>     limited to running `hg` instead of `hg.exe` in a venv, so maybe this
>>     is fixable by compiling wrapper.exe and not installing the `hg`
>>     script
>>     when running `setup.py` on Windows.) Â I also need to finish up
>>     the py3
>>     porting series for mercurial_keyring, as that still has a few issues.
>>
>>     I think that it would be beneficial to have a beta period for thg
>>     where both py2 and py3 are built (like we did with hg), to find some
>>     of the issues that pytype isn't catching.  I'll probably regret this
>>     because IDK how long I can sustain the current pace, but if we
>>     can get
>>     the Windows and Mac packaging done for 5.8, maybe 5.8 can be the beta
>>     period and 5.9 is py3 only? Â (It might be OK if the packaging isn't
>>     ready until 5.8.1, since Yuya seems to be OK with landing packaging
>>     and py3 fixes on stable if they aren't crazy.) Â I think Greg made
>>     some
>>     MSI related enhancement to PyOxidizer recently, but IDK what the
>>     means
>>     for the state of things, or how far away a macOS *.app bundle is.
>>     Worst case scenario, I can build thg 5.9 with hg 5.8.2 if thg
>>     progress
>>     can't keep pace.  I just don't want that going on forever.
>
>     I think this plan is sensible and you should proceed with it.
>
>>
>>>     I am CC'ing Greg who proposed to help at the time, as well as
>>>     Matt, the
>>>     maintainer, since they
>>>     might know better than anyone where we're currently standing.
>>>
>>>     Thanks,
>>>     Raphaël
>>>
>>     _______________________________________________
>>     Mercurial-devel mailing list
>>     Mercurial-devel at mercurial-scm.org
>>     <mailto:Mercurial-devel at mercurial-scm.org>
>>     https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>>     <https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20210901/01963475/attachment.html>