On Mon, Mar 4, 2019 at 8:26 AM Pulkit Goyal <7895pul...@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...
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
