Making hg 5.0 as beta release with python 3 support.

[Gregory Szorc]

On Mon, Mar 4, 2019 at 8:26 AM Pulkit Goyal <7895pulkit at gmail.com> wrote:

> Hey everyone,
>
> I hope everything is going well.
>
> After years of work on porting mercurial to Python 3 by everyone, we are
> close, very close. Right now, only 5 tests fail on python 3 and there are 4
> regressions (tests which were passing earlier and started failing
> recently). Few days ago, I installed mercurial using Python 3 as default
> mercurial on my personal system. Things are working good. Things which I
> have noticed not working are:
>
> 1) phabricator extension
> 2) curses interface
> 3) out of core extensions like evolve, topic
>
> I will try to fix 1) and 2) this week.
>
> That said, I will like to propose to mark the upcoming major release hg
> 5.0 as the beta release with Python 3 support. We have more than 50 days
> before that release. We can:
>
> 1) start testing python 3 more aggressively by having more people install
> hg on py3 by default
> 2) advertising that next release will be py3 beta will give enough time
> for extensions author to port their extensions
> 3) help/advice/guide extensions authors on how to port their extensions to
> Py3 while keeping py2 compatibility
>
> How do you feel?
>

I wholeheartedly approve of making the next release beta quality for Python
3. Even with a few test failures, the core distribution is effectively
Python 3 compatible as far as we know/test it to be. Now is the time to
encourage people to use Mercurial with Python 3.

I do think we should do something about 3rd party extensions and Python 3
compatibility to deal with the "nearly every extension will be broken on
Python 3" problem. I've been thinking about introducing special syntax into
.py files that the extension loader can key off of to determine whether to
load an extension. e.g. `HGEXT_MINIMUM_PYTHON_VERSION = '3.5'`. Basically,
I think extensions should be incompatible by default unless they opt in
somehow. I have no firm plans to implement that though. Perhaps someone can
beat me to it. FWIW we could also leverage similar functionality for
additional filtering. e.g. as a better Mercurial version compatibility and
dependency mechanism. Existing primitives for doing this are overly simple
and deficient.

We also have a long tail of packaging problems with Python 3. At some point
we'll need to teach the various installers/packages about Python 3. Very
little of this work has been done. It isn't critical for a beta release.
But if we can't get the beta in front of people, then that makes it harder
to promote to stable. I am actively hacking on the Windows installers with
one goal being to make supporting Python 3 easier. I have no plans to work
on other packaging. But I could...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190304/0448df1a/attachment.html>