##// END OF EJS Templates
hgweb: create dedicated type for WSGI responses...
hgweb: create dedicated type for WSGI responses We have refactored the request side of WSGI processing into a dedicated type. Now let's do the same thing for the response side. We invent a ``wsgiresponse`` type. It takes an instance of a request (for consulation) and the WSGI application's "start_response" handler. The type basically allows setting the HTTP status line, response headers, and the response body. The WSGI application calls sendresponse() to start sending output. Output is emitted as a generator to be fed through the WSGI application. According to PEP 3333, this is the preferred way for output to be transmitted. (Our legacy ``wsgirequest`` exposed a write() to send data. We do not wish to support this API because it isn't recommended by PEP 3333.) The wire protocol code has been ported to use the new API. Differential Revision: https://phab.mercurial-scm.org/D2775

File last commit:

r19296:da16d21c stable
r36877:a88d68dc default
Show More
extensions.txt
35 lines | 1.2 KiB | text/plain | TextLexer
Mercurial has the ability to add new features through the use of
extensions. Extensions may add new commands, add options to
existing commands, change the default behavior of commands, or
implement hooks.
To enable the "foo" extension, either shipped with Mercurial or in the
Python search path, create an entry for it in your configuration file,
like this::
[extensions]
foo =
You may also specify the full path to an extension::
[extensions]
myfeature = ~/.hgext/myfeature.py
See :hg:`help config` for more information on configuration files.
Extensions are not loaded by default for a variety of reasons:
they can increase startup overhead; they may be meant for advanced
usage only; they may provide potentially dangerous abilities (such
as letting you destroy or modify history); they might not be ready
for prime time; or they may alter some usual behaviors of stock
Mercurial. It is thus up to the user to activate extensions as
needed.
To explicitly disable an extension enabled in a configuration file of
broader scope, prepend its path with !::
[extensions]
# disabling extension bar residing in /path/to/extension/bar.py
bar = !/path/to/extension/bar.py
# ditto, but no path was supplied for extension baz
baz = !