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

# py3kcompat.py - compatibility definitions for running hg in py3k
#
# Copyright 2010 Renato Cunha <[e-mail]>
#
# 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()