##// END OF EJS Templates
exchange: move disabling of rev-branch-cache bundle part out of narrow...
exchange: move disabling of rev-branch-cache bundle part out of narrow I'm attempting to refactor changegroup code in order to better support alternate storage backends. The narrow extension is performing a lot of monkeypatching to this code and it is making it difficult to reason about how everything works. I'm reasonably certain I would be unable to abstract storage without requiring extensive rework of narrow. I believe it is less effort to move narrow code into core so it can be accounted for when changegroup code is refactored. So I'll be doing that. The first part of this is integrating the disabling of the cache:rev-branch-cache bundle2 part into core. This doesn't seem like it is related to changegroup, but narrow's modifications to changegroup are invasive and also require taking its code for bundle generation and exchange into core in order for the changegroup code to work. Differential Revision: https://phab.mercurial-scm.org/D4007

File last commit:

r37513:b1fb341d default
r38813:ab765bc4 default
Show More
__init__.py
62 lines | 2.3 KiB | text/x-python | PythonLexer
# Copyright (c) 2017-present, Gregory Szorc
# All rights reserved.
#
# This software may be modified and distributed under the terms
# of the BSD license. See the LICENSE file for details.
"""Python interface to the Zstandard (zstd) compression library."""
from __future__ import absolute_import, unicode_literals
# This module serves 2 roles:
#
# 1) Export the C or CFFI "backend" through a central module.
# 2) Implement additional functionality built on top of C or CFFI backend.
import os
import platform
# Some Python implementations don't support C extensions. That's why we have
# a CFFI implementation in the first place. The code here import one of our
# "backends" then re-exports the symbols from this module. For convenience,
# we support falling back to the CFFI backend if the C extension can't be
# imported. But for performance reasons, we only do this on unknown Python
# implementation. Notably, for CPython we require the C extension by default.
# Because someone will inevitably want special behavior, the behavior is
# configurable via an environment variable. A potentially better way to handle
# this is to import a special ``__importpolicy__`` module or something
# defining a variable and `setup.py` could write the file with whatever
# policy was specified at build time. Until someone needs it, we go with
# the hacky but simple environment variable approach.
_module_policy = os.environ.get('PYTHON_ZSTANDARD_IMPORT_POLICY', 'default')
if _module_policy == 'default':
if platform.python_implementation() in ('CPython',):
from zstd import *
backend = 'cext'
elif platform.python_implementation() in ('PyPy',):
from zstd_cffi import *
backend = 'cffi'
else:
try:
from zstd import *
backend = 'cext'
except ImportError:
from zstd_cffi import *
backend = 'cffi'
elif _module_policy == 'cffi_fallback':
try:
from zstd import *
backend = 'cext'
except ImportError:
from zstd_cffi import *
backend = 'cffi'
elif _module_policy == 'cext':
from zstd import *
backend = 'cext'
elif _module_policy == 'cffi':
from zstd_cffi import *
backend = 'cffi'
else:
raise ImportError('unknown module import policy: %s; use default, cffi_fallback, '
'cext, or cffi' % _module_policy)