histedit: add templating support to histedit's rule file generation This will allow users to customize the display of the rule list for the free-form segment that we don't interpret. We've had users want to add things like bookmark names or similar to the rule list as a convenience, which seems reasonable. Differential Revision: https://phab.mercurial-scm.org/D5742

py3: account for demand import difference between Python versions Our lazy importer for Python 3 will validate that modules are loadable before returning a stub module object. This is different from Python 2, which will always return a stub module object. While we could change behavior of the Python 3 demand importer, that seems like a problem for another day. This commit teaches test-extension.t about that difference in behavior. Differential Revision: https://phab.mercurial-scm.org/D5798

tests: use unimported modules in test-demandimport.py contextlib isn't a good module to test because it is likely already imported by code above. Let's use modules that shouldn't have been imported. And let's verify that with asserts. Differential Revision: https://phab.mercurial-scm.org/D5797

py3: conditionalize test-demandimport.py for Python 3 The Python 3 lazy importer uses the LazyLoader that is part of importlib. On Python 3 and later, LazyLoader is implemented using a custom module type that defines a __getattribute__ which triggers module loading. Furthermore, there are additional differences as well. For example, it appears that Python 3 will return an existing sys.modules entry instead of constructing a new module object. This commit adds additional test coverage for lazy importing behavior to cover the differences between Python 2 and 3. This reveals that the test and some lazy import functionality is kinda busted. For example, the test assumes "contextlib" will be lazy. But in reality an import before it has already imported contextlib! There's definitely room to improve the behavior of the demand importer code, both for Python 2 and 3. But at least the test passes on Python 3 now. Differential Revision: https://phab.mercurial-scm.org/D5796

py3: replace print() with assert in test-demandimport.py Behavior of demand imports behaves differently between Python 2 and 3. .out files do not support conditional output the way that .t files do. In order to make this test work on Python 3, we'll need to make the test itself conditional. The first step of this is to port the test to not use a .out file to compare output. Unfortunately, we can't easily use the unittest framework for defining this test because putting import statements in functions changes the behavior of the demand importer (at least on Python 2). So, we effectively replace a bunch of print() with assert statements. This makes the test a bit annoying to debug, as the test will stop at first assertion failure. But we don't exactly have a good alternative. Differential Revision: https://phab.mercurial-scm.org/D5795

py3: pass str into grp.getgrnam grp.getgrnam expects str on Python 3. This fixes test-acl.t on Python 3. Differential Revision: https://phab.mercurial-scm.org/D5794

montone: fix addition to list by using .append() instead of '+' Differential Revision: https://phab.mercurial-scm.org/D5739

tests: give up and make setsockopt() calls optional in the output I can't figure out what causes these calls to happen or not, and I weary of dealing with them. End the madness for now by marking them all as optional lines of output. Differential Revision: https://phab.mercurial-scm.org/D5762

py3: fix test-remotefilelog-repack.t This is uglier, but more obviously correct in my opinion. I guess Python 3 doesn't hang on to the exception as long, which seems reasonable. Differential Revision: https://phab.mercurial-scm.org/D5781

tests: alter email `From` line to a value that's consistently parsed Python2: >>> email.header.decode_header('=?UTF-8?q?Rapha=C3=ABl=20Hertzog?= <hertzog@debian.org>') [('Rapha\xc3\xabl Hertzog', 'utf-8'), ('<hertzog@debian.org>', None)] Python3: >>> email.header.decode_header('=?UTF-8?q?Rapha=C3=ABl=20Hertzog?= <hertzog@debian.org>') [(b'Rapha\xc3\xabl Hertzog', 'utf-8'), (b' <hertzog@debian.org>', None)] So alter the input to an input that parses to the same result consistently. After skimming the relevant RFC (1342), I'm not sure if what we had was valid, or how I could modify it to be more consistent. Differential Revision: https://phab.mercurial-scm.org/D5769