tests/filterpyflakes.py
author Gregory Szorc <gregory.szorc@gmail.com>
Wed, 08 Jul 2015 16:19:09 -0700
changeset 25761 0d37b9b21467
parent 21294 1ae3cd6f836c
child 26023 48671378daeb
permissions -rwxr-xr-x
hg: support for auto sharing stores when cloning Many 3rd party consumers of Mercurial have created wrappers to essentially perform clone+share as a single operation. This is especially popular in automated processes like continuous integration systems. The Jenkins CI software and Mozilla's Firefox release automation infrastructure have both implemented custom code that effectively perform clone+share. The common use case here is that clients want to obtain N>1 checkouts while minimizing disk space and network requirements. Furthermore, they often don't care that a clone is an exact mirror of a remote: they are simply looking to obtain checkouts of specific revisions. When multiple third parties implement a similar feature, it's a good sign that the feature is worth adding to the core product. This patch adds support for an easy-to-use clone+share feature. The internal "clone" function now accepts options to control auto sharing during clone. When the auto share mode is active, a store will be created/updated under the base directory specified and a new repository pointing to the shared store will be created at the path specified by the user. The share extension has grown the ability to pass these options into the clone command/function. No command line options for this feature are added because we don't feel the feature will be popular enough to warrant their existence. There are two modes for auto share mode. In the default mode, the shared repo is derived from the first changeset (rev 0) in the remote repository. This enables related repositories existing at different URLs to automatically use the same storage. In environments that operate several repositories (separate repo for branch/head/bookmark or separate repo per user), this has the potential to drastically reduce storage and network requirements. In the other mode, the name is derived from the remote's path/URL.

#!/usr/bin/env python

# Filter output by pyflakes to control which warnings we check

import sys, re, os

def makekey(typeandline):
    """
    for sorting lines by: msgtype, path/to/file, lineno, message

    typeandline is a sequence of a message type and the entire message line
    the message line format is path/to/file:line: message

    >>> makekey((3, 'example.py:36: any message'))
    (3, 'example.py', 36, ' any message')
    >>> makekey((7, 'path/to/file.py:68: dummy message'))
    (7, 'path/to/file.py', 68, ' dummy message')
    >>> makekey((2, 'fn:88: m')) > makekey((2, 'fn:9: m'))
    True
    """

    msgtype, line = typeandline
    fname, line, message = line.split(":", 2)
    # line as int for ordering 9 before 88
    return msgtype, fname, int(line), message


lines = []
for line in sys.stdin:
    # We whitelist tests (see more messages in pyflakes.messages)
    pats = [
            (r"imported but unused", None),
            (r"local variable '.*' is assigned to but never used", None),
            (r"unable to detect undefined names", None),
            (r"undefined name '.*'",
             r"undefined name '(WindowsError|memoryview)'")
           ]

    for msgtype, (pat, excl) in enumerate(pats):
        if re.search(pat, line) and (not excl or not re.search(excl, line)):
            break # pattern matches
    else:
        continue # no pattern matched, next line
    fn = line.split(':', 1)[0]
    f = open(os.path.join(os.path.dirname(os.path.dirname(__file__)), fn))
    data = f.read()
    f.close()
    if 'no-' 'check-code' in data:
        continue
    lines.append((msgtype, line))

for msgtype, line in sorted(lines, key=makekey):
    sys.stdout.write(line)
print

# self test of "undefined name" detection for other than 'memoryview'
if False:
    print undefinedname