Mercurial > hg
view mercurial/py3kcompat.py @ 28164:ad11edefa7c4
localrepo: move new repo requirements into standalone function (API)
This patch extracts the code for determining requirements for a new
repo into a standalone function. By doing so, future code that will
perform an in-place repository upgrade (e.g. to generaldelta) can
examine the set of proposed new requirements and possibly take
additional actions (such as adding dotencode or fncache) when
performing the upgrade.
This patch is marked as API because _baserequirements (which was added
in b090601a80d1 so extensions could override it) has been removed and
will presumably impact whatever extension it was added for. Consumers
should be able to monkeypatch the new function to achieve the same
functionality.
The "create" argument has been dropped because the function is only
called in one location and "create" is always true in that case.
While it makes logical sense for this code to be a method so extensions
can implement a custom repo class / method to override it, this won't
actually work. This is because requirements determination occurs during
localrepository.__init__ and this is before the "reposetup"
"callback" is fired. So, the only way for extensions to customize
requirements would be to overwrite localrepo.localrepository or to
monkeypatch a function on a module during extsetup(). Since we try to
keep localrepository small, we use a standalone function. There is
probably room to offer extensions a "hook" point to alter repository
creation. But that is scope bloat.
author | Gregory Szorc <gregory.szorc@gmail.com> |
---|---|
date | Mon, 15 Feb 2016 13:20:20 -0800 |
parents | 5bfd01a3c2a9 |
children |
line wrap: on
line source
# py3kcompat.py - compatibility definitions for running hg in py3k # # Copyright 2010 Renato Cunha <renatoc@gmail.com> # # This software may be used and distributed according to the terms of the # GNU General Public License version 2 or any later version. from __future__ import absolute_import import builtins import numbers Number = numbers.Number def bytesformatter(format, args): '''Custom implementation of a formatter for bytestrings. This function currently relies on the string formatter to do the formatting and always returns bytes objects. >>> bytesformatter(20, 10) 0 >>> bytesformatter('unicode %s, %s!', ('string', 'foo')) b'unicode string, foo!' >>> bytesformatter(b'test %s', 'me') b'test me' >>> bytesformatter('test %s', 'me') b'test me' >>> bytesformatter(b'test %s', b'me') b'test me' >>> bytesformatter('test %s', b'me') b'test me' >>> bytesformatter('test %d: %s', (1, b'result')) b'test 1: result' ''' # The current implementation just converts from bytes to unicode, do # what's needed and then convert the results back to bytes. # Another alternative is to use the Python C API implementation. if isinstance(format, Number): # If the fixer erroneously passes a number remainder operation to # bytesformatter, we just return the correct operation return format % args if isinstance(format, bytes): format = format.decode('utf-8', 'surrogateescape') if isinstance(args, bytes): args = args.decode('utf-8', 'surrogateescape') if isinstance(args, tuple): newargs = [] for arg in args: if isinstance(arg, bytes): arg = arg.decode('utf-8', 'surrogateescape') newargs.append(arg) args = tuple(newargs) ret = format % args return ret.encode('utf-8', 'surrogateescape') builtins.bytesformatter = bytesformatter origord = builtins.ord def fakeord(char): if isinstance(char, int): return char return origord(char) builtins.ord = fakeord if __name__ == '__main__': import doctest doctest.testmod()