Mercurial > hg
view mercurial/py3kcompat.py @ 27764:dd0c5f4d1b53
util: adjust 'datapath' to be correct in a frozen OS X package
Apparently unlike py2exe, py2app copies the Mercurial source tree as-is to a
Contents/Resources subdirectory of an app bundle, and places its binary stub in
Contents/MacOS. (The Windows install has the 'hgext' and 'mercurial' modules in
'lib/library.zip', while the help and templates subdirectories have been moved
out of the mercurial directory to the root of the installation. I assume that
the python code living in a zip file is why "py2exe doesn't support __file__".)
Therefore, prior to this change, Mercurial in a frozen app bundle on OS X would
go looking for help *.txt, templates and locale info in Contents/MacOS, where
they don't exist.
There are only a handful of places that test for frozen, and not all of them are
wrong for OS X, so it seems wiser to handle them on a case by case basis, rather
that try to change mainfrozen(). The remaining cases are:
1) util.hgexecutable() wrongly points to the bundled python executable, and
affects $HG in util.system() launched processes (e.g. external hooks)
2) util.hgcmd() wrongly points to the bundled python executable, but it seems
to only affect 'hg serve -d'
3) hook._pythonhook() may be OK, since I didn't see anything outrageous when
printing sys.path from an internal hook. I'm not sure if this special
case is needed on OS X though.
4) sslutil._plainapplepython() is OK, because sys.executable is not
/usr/bin/python, nor is it in /System/Library/Frameworks
author | Matt Harbison <matt_harbison@yahoo.com> |
---|---|
date | Sun, 10 Jan 2016 17:49:01 -0500 |
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()