tests: python executable path should always be globbed Although this is coming in under the guise of consistency, part of the desire for this is that at least as part of the official Solaris builds, we build with a versioned python interpreter, such as "python2.7", which doesn't match "*python".

crecord: use ui.interface to choose curses interface use ui.interface to select curses mode, instead of experimental.crecord

ui: add new config flag for interface selection This patch introduces a new config flag ui.interface to select the interface for interactive commands. It currently only applies to chunks selection. The config can be overridden on a per feature basis with the flag ui.interface.<feature>. features for the moment can only be 'chunkselector', moving forward we expect to have 'histedit' and other commands there. If an incorrect value is given to ui.interface we print a warning and use the default interface: text. If HGPLAIN is specified we also use the default interface: text. Note that we fail quickly if a feature does not handle all the interfaces that we permit in ui.interface; in future, we could design a fallback path (e.g. blackpearl to curses, curses to text), but let's leave that until we need it.

extensions: also search for extension in the 'hgext3rd' package Mercurial extensions are not meant to be normal python package/module. Yet the lack of an official location to install them means that a lot of them actually install as root level python package, polluting the global Python package namespace and risking collision with more legit packages. As we recently discovered, core python actually support namespace package. A way for multiples distinct "distribution" to share a common top level package without fear of installation headache. (Namespace package allow submodule installed in different location (of the 'sys.path') to be imported properly. So we are fine as long as extension includes a proper 'hgext3rd.__init__.py' to declare the namespace package.) Therefore we introduce a 'hgext3rd' namespace packages and search for extension in it. We'll then recommend third extensions to install themselves in it. Strictly speaking we could just get third party extensions to install in 'hgext' as it is also a namespace package. However, this would make the integration of formerly third party extensions in the main distribution more complicated as the third party install would overwrite the file from the main install. Moreover, having an explicit split between third party and core extensions seems like a good idea. The name 'hgext3rd' have been picked because it is short and seems explicit enough. Other alternative I could think of where: - hgextcontrib - hgextother - hgextunofficial