yes, you can even combine the two as pre-commit install --install-hooks

we're fixing the root cause in setuptools-scm though so that workaround shouldn't be necessary indefinitely

yeah you can probably narrow it to a 2-repository reproduction: set GIT_INDEX to an unrelated git repo and attempt to install repo 2

A workaround is to call pre-commit install-hooks manually once outside of git commit (pre-commit will reuse that cache)

nah it's very much not that -- I triaged it above, this is the environment variables that git puts into the environment interfering with whatever git commands setuptools-scm is running

for instance if you take the above reproduction and instead call the script directly it works fine:

$ diff -u t.sh.old t.sh
--- t.sh.old	2019-12-13 13:20:06.431135823 -0800
+++ t.sh	2019-12-13 13:20:09.219017427 -0800
@@ -16,5 +16,4 @@
 "$PWD/venv/bin/pip" install "$PWD/black"
 EOF
 chmod +x "$PWD/y/.git/modules/z/hooks/pre-commit"
-cd y/z
-git commit -m "test"
+"$PWD/y/.git/modules/z/hooks/pre-commit"

deleted the test, seems weird to not have a regression test for this fix but that's not my call!

errr actually you're looking for language: pygrep -- here's some examples: https://github.com/pre-commit/pygrep-hooks

I'm looking for a hook that disallows arbitrary strings ("NOCOMMIT" or "TODO") for instance, where if a file has that string in it, the hook fails and does not allow for a commit.

pre-commit has a "language" which makes it easy to configure hooks like this: language: fail

Resolves #8144

here's the same script that was used in the reproduction for #8144:

$ python3 ../wut/t.py mypy --pretty ../wut/t.py 
../wut/t.py:6: error: Incompatible types in assignment (expression has type
"str", variable has type "int")
    x: int = 'nope'
             ^
Found 1 error in 1 file (checked 1 source file)

version information:

$ mypy --version
mypy 0.750
$ python3 --version --version
Python 3.6.8 (default, Oct  7 2019, 12:59:55) 
[GCC 8.3.0]

test pty script:

import errno
import os
import subprocess
import sys

x: int = 'nope'


class Pty(object):
    def __init__(self):
        self.r = self.w = None

    def __enter__(self):
        self.r, self.w = os.openpty()

        return self

    def close_w(self):
        if self.w is not None:
            os.close(self.w)
            self.w = None

    def close_r(self):
        assert self.r is not None
        os.close(self.r)
        self.r = None

    def __exit__(self, exc_type, exc_value, traceback):
        self.close_w()
        self.close_r()


def cmd_output_p(*cmd, **kwargs):
    with open(os.devnull) as devnull, Pty() as pty:
        kwargs = {'stdin': devnull, 'stdout': pty.w, 'stderr': pty.w}
        proc = subprocess.Popen(cmd, **kwargs)
        pty.close_w()

        buf = b''
        while True:
            try:
                bts = os.read(pty.r, 4096)
            except OSError as e:
                if e.errno == errno.EIO:
                    bts = b''
                else:
                    raise
            else:
                buf += bts
            if not bts:
                break

    return proc.wait(), buf, None


_, buf, _ = cmd_output_p(*sys.argv[1:])
sys.stdout.buffer.write(buf)

Output:

$ python3 t.py mypy --pretty t.py
t.py:6: error:
Incompatible
types
in
assignment
(expression
has
type
"str",
variable
has
type
"int")
    x: int = 'nope'
             ^
Found 1 error in 1 file (checked 1 source file)

the output is colored (as expected) but has strange line breaks, almost like there's some wrapping logic that assumes the terminal is zero width or something (?)

Interestingly, the output appears correct when not using --pretty:

$ python3 t.py mypy t.py
t.py:6: error: Incompatible types in assignment (expression has type "str", variable has type "int")
Found 1 error in 1 file (checked 1 source file)

going a bit further, here's some info that potentially confirms my suspicion:

$ python3 t.py python3 -c 'import shutil; print(shutil.get_terminal_size())'
os.terminal_size(columns=0, lines=0)

I've created https://github.com/pypa/setuptools_scm/issues/381 to track this

this issue is oddly specific but I here's the reproduction:

#!/usr/bin/env bash
set -euxo pipefail

rm -rf y z home black venv

git clone https://github.com/psf/black

export PRE_COMMIT_HOME="$PWD/home"
git init y
git init z
git -C z commit --allow-empty -m 'commit!'
git -C y submodule add "$PWD/z"
cat > "$PWD/y/.git/modules/z/hooks/pre-commit" <<EOF
#!/usr/bin/env bash
virtualenv "$PWD/venv"
"$PWD/venv/bin/pip" install "$PWD/black"
EOF
chmod +x "$PWD/y/.git/modules/z/hooks/pre-commit"
cd y/z
git commit -m "test"

this currently ends as:

$ bash t.sh 
+ rm -rf y z home black venv
+ git clone https://github.com/psf/black
Cloning into 'black'...
remote: Enumerating objects: 14, done.
remote: Counting objects: 100% (14/14), done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 3284 (delta 7), reused 2 (delta 1), pack-reused 3270
Receiving objects: 100% (3284/3284), 3.72 MiB | 2.15 MiB/s, done.
Resolving deltas: 100% (2223/2223), done.
+ export PRE_COMMIT_HOME=/tmp/z/home
+ PRE_COMMIT_HOME=/tmp/z/home
+ git init y
Initialized empty Git repository in /tmp/z/y/.git/
+ git init z
Initialized empty Git repository in /tmp/z/z/.git/
+ git -C z commit --allow-empty -m 'commit!'
[master (root-commit) 4f0b4dc] commit!
+ git -C y submodule add /tmp/z/z
Cloning into '/tmp/z/y/z'...
done.
+ cat
+ chmod +x /tmp/z/y/.git/modules/z/hooks/pre-commit
+ cd y/z
+ git commit -m test
Using real prefix '/usr'
Path not in prefix '/home/asottile/opt/venv/include/python3.6m' '/usr'
New python executable in /tmp/z/venv/bin/python3
Also creating executable in /tmp/z/venv/bin/python
Installing setuptools, pip, wheel...
done.
Processing /tmp/z/black
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... error
    ERROR: Command errored out with exit status 1:
     command: /tmp/z/venv/bin/python3 /tmp/z/venv/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py prepare_metadata_for_build_wheel /tmp/tmp33fojq8s
         cwd: /tmp/pip-req-build-6b2fw0yg
    Complete output (36 lines):
    Traceback (most recent call last):
      File "/tmp/z/venv/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py", line 257, in <module>
        main()
      File "/tmp/z/venv/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py", line 240, in main
        json_out['return_val'] = hook(**hook_input['kwargs'])
      File "/tmp/z/venv/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py", line 110, in prepare_metadata_for_build_wheel
        return hook(metadata_directory, config_settings)
      File "/tmp/pip-build-env-ydhjt6g5/overlay/lib/python3.6/site-packages/setuptools/build_meta.py", line 156, in prepare_metadata_for_build_wheel
        self.run_setup()
      File "/tmp/pip-build-env-ydhjt6g5/overlay/lib/python3.6/site-packages/setuptools/build_meta.py", line 142, in run_setup
        exec(compile(code, __file__, 'exec'), locals())
      File "setup.py", line 97, in <module>
        "blackd=blackd:patched_main [d]",
      File "/tmp/pip-build-env-ydhjt6g5/overlay/lib/python3.6/site-packages/setuptools/__init__.py", line 145, in setup
        return distutils.core.setup(**attrs)
      File "/usr/lib/python3.6/distutils/core.py", line 108, in setup
        _setup_distribution = dist = klass(attrs)
      File "/tmp/pip-build-env-ydhjt6g5/overlay/lib/python3.6/site-packages/setuptools/dist.py", line 448, in __init__
        k: v for k, v in attrs.items()
      File "/usr/lib/python3.6/distutils/dist.py", line 281, in __init__
        self.finalize_options()
      File "/tmp/pip-build-env-ydhjt6g5/overlay/lib/python3.6/site-packages/setuptools/dist.py", line 740, in finalize_options
        ep.load()(self)
      File "/tmp/pip-build-env-ydhjt6g5/overlay/lib/python3.6/site-packages/setuptools/dist.py", line 747, in _finalize_setup_keywords
        ep.load()(self, ep.name, value)
      File "/tmp/pip-build-env-ydhjt6g5/overlay/lib/python3.6/site-packages/setuptools_scm/integration.py", line 17, in version_keyword
        dist.metadata.version = get_version(**value)
      File "/tmp/pip-build-env-ydhjt6g5/overlay/lib/python3.6/site-packages/setuptools_scm/__init__.py", line 150, in get_version
        parsed_version = _do_parse(config)
      File "/tmp/pip-build-env-ydhjt6g5/overlay/lib/python3.6/site-packages/setuptools_scm/__init__.py", line 113, in _do_parse
        "use git+https://github.com/user/proj.git#egg=proj" % config.absolute_root
    LookupError: setuptools-scm was unable to detect version for '/tmp/pip-req-build-6b2fw0yg'.
    
    Make sure you're either building from a fully intact git repository or PyPI tarballs. Most other sources (such as GitHub's tarballs, a git checkout without the .git folder) don't contain the necessary metadata and will not work.
    
    For example, if you're using pip, instead of https://github.com/user/proj/archive/master.zip use git+https://github.com/user/proj.git#egg=proj
    ----------------------------------------
ERROR: Command errored out with exit status 1: /tmp/z/venv/bin/python3 /tmp/z/venv/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py prepare_metadata_for_build_wheel /tmp/tmp33fojq8s Check the logs for full command output.

guess at a fix

I don't know much about setuptools-scm, but I suspect a patch with functionality similar to this would fix the problem

Original issue: https://github.com/psf/black/issues/1180

and here is a minimal reproduction not involving pre-commit:

#!/usr/bin/env bash
set -euxo pipefail

rm -rf y z home black venv

git clone https://github.com/psf/black

export PRE_COMMIT_HOME="$PWD/home"
git init y
git init z
git -C z commit --allow-empty -m 'commit!'
git -C y submodule add "$PWD/z"
cat > "$PWD/y/.git/modules/z/hooks/pre-commit" <<EOF
#!/usr/bin/env bash
virtualenv "$PWD/venv"
"$PWD/venv/bin/pip" install "$PWD/black"
EOF
chmod +x "$PWD/y/.git/modules/z/hooks/pre-commit"
cd y/z
git commit -m "test"

that's very helpful! it also crashes for me inside of a submodule

here's a more minimal reproduction:

#!/usr/bin/env bash
set -euxo pipefail

rm -rf y z home

export PRE_COMMIT_HOME="$PWD/home"
git init y
git init z
git -C z commit --allow-empty -m 'commit!'
git -C y submodule add "$PWD/z"
cat > "$PWD/y/z/.pre-commit-config.yaml" <<EOF
repos:
-   repo: https://github.com/psf/black
    rev: 19.10b0
    hooks:
    -   id: black
EOF
cd y/z
pre-commit install
git commit -m "test"

ah I think you need

    rf'^(?P<indent> *)\.\. (jupyter-execute::|(code|code-block|sourcecode|ipython):: {PY_LANGS})\n' 

can you show your patch? maybe I can help :)

I believe (?) it would be extending this line to also match jupyter-execute: https://github.com/asottile/blacken-docs/blob/109732aa39a1cafd631e5015b395fac02eb16ee0/blacken_docs.py#L25

foo@foo-VirtualBox:~/root/microservices/billing$ pre-commit install
pre-commit installed at /home/foo/root/.git/modules/microservices/billing/hooks/pre-commit
foo@foo-VirtualBox:~/root/microservices/billing$ git status
On branch dev
Your branch is up to date with 'origin/dev'.

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   a.py

foo@foo-VirtualBox:~/root/microservices/billing$ git commit -m "foo"
[INFO] Installing environment for https://github.com/psf/black.
[INFO] Once installed this environment will be reused.
[INFO] This may take a few minutes...
An unexpected error has occurred: CalledProcessError: Command: ('/home/foo/.cache/pre-commit/repox7sb94wd/py_env-python3.7/bin/python3.7', '/home/foo/.cache/pre-commit/repox7sb94wd/py_env-python3.7/bin/pip', 'install', '.')
Return code: 1
Expected return code: 0
Output: 
    Processing /home/foo/.cache/pre-commit/repox7sb94wd
      Installing build dependencies: started
      Installing build dependencies: finished with status 'done'
      Getting requirements to build wheel: started
      Getting requirements to build wheel: finished with status 'done'
        Preparing wheel metadata: started
        Preparing wheel metadata: finished with status 'error'
    
Errors: 
        ERROR: Command errored out with exit status 1:
         command: /home/foo/.cache/pre-commit/repox7sb94wd/py_env-python3.7/bin/python3.7 /home/foo/.cache/pre-commit/repox7sb94wd/py_env-python3.7/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py prepare_metadata_for_build_wheel /tmp/tmpq2o70erc
             cwd: /tmp/pip-req-build-sy15f1qc
        Complete output (36 lines):
        Traceback (most recent call last):
          File "/home/foo/.cache/pre-commit/repox7sb94wd/py_env-python3.7/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 257, in <module>
            main()
          File "/home/foo/.cache/pre-commit/repox7sb94wd/py_env-python3.7/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 240, in main
            json_out['return_val'] = hook(**hook_input['kwargs'])
          File "/home/foo/.cache/pre-commit/repox7sb94wd/py_env-python3.7/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py", line 110, in prepare_metadata_for_build_wheel
            return hook(metadata_directory, config_settings)
          File "/tmp/pip-build-env-ewlgs0nn/overlay/lib/python3.7/site-packages/setuptools/build_meta.py", line 156, in prepare_metadata_for_build_wheel
            self.run_setup()
          File "/tmp/pip-build-env-ewlgs0nn/overlay/lib/python3.7/site-packages/setuptools/build_meta.py", line 142, in run_setup
            exec(compile(code, __file__, 'exec'), locals())
          File "setup.py", line 65, in <module>
            "blackd=blackd:patched_main [d]",
          File "/tmp/pip-build-env-ewlgs0nn/overlay/lib/python3.7/site-packages/setuptools/__init__.py", line 145, in setup
            return distutils.core.setup(**attrs)
          File "/home/linuxbrew/.linuxbrew/Cellar/python/3.7.5/lib/python3.7/distutils/core.py", line 108, in setup
            _setup_distribution = dist = klass(attrs)
          File "/tmp/pip-build-env-ewlgs0nn/overlay/lib/python3.7/site-packages/setuptools/dist.py", line 448, in __init__
            k: v for k, v in attrs.items()
          File "/home/linuxbrew/.linuxbrew/Cellar/python/3.7.5/lib/python3.7/distutils/dist.py", line 292, in __init__
            self.finalize_options()
          File "/tmp/pip-build-env-ewlgs0nn/overlay/lib/python3.7/site-packages/setuptools/dist.py", line 740, in finalize_options
            ep.load()(self)
          File "/tmp/pip-build-env-ewlgs0nn/overlay/lib/python3.7/site-packages/setuptools/dist.py", line 747, in _finalize_setup_keywords
            ep.load()(self, ep.name, value)
          File "/tmp/pip-build-env-ewlgs0nn/overlay/lib/python3.7/site-packages/setuptools_scm/integration.py", line 17, in version_keyword
            dist.metadata.version = get_version(**value)
          File "/tmp/pip-build-env-ewlgs0nn/overlay/lib/python3.7/site-packages/setuptools_scm/__init__.py", line 150, in get_version
            parsed_version = _do_parse(config)
          File "/tmp/pip-build-env-ewlgs0nn/overlay/lib/python3.7/site-packages/setuptools_scm/__init__.py", line 113, in _do_parse
            "use git+https://github.com/user/proj.git#egg=proj" % config.absolute_root
        LookupError: setuptools-scm was unable to detect version for '/tmp/pip-req-build-sy15f1qc'.
        
        Make sure you're either building from a fully intact git repository or PyPI tarballs. Most other sources (such as GitHub's tarballs, a git checkout without the .git folder) don't contain the necessary metadata and will not work.
        
        For example, if you're using pip, instead of https://github.com/user/proj/archive/master.zip use git+https://github.com/user/proj.git#egg=proj
        ----------------------------------------
    ERROR: Command errored out with exit status 1: /home/foo/.cache/pre-commit/repox7sb94wd/py_env-python3.7/bin/python3.7 /home/foo/.cache/pre-commit/repox7sb94wd/py_env-python3.7/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py prepare_metadata_for_build_wheel /tmp/tmpq2o70erc Check the logs for full command output.
    
Check the log at /home/foo/.cache/pre-commit/pre-commit.log
foo@foo-VirtualBox:~/root/microservices/billing$ cat .pre-commit-config.yaml 
repos:
  - repo: https://github.com/psf/black
    rev: stable
    hooks:
      - id: black
        language_version: python3.7
foo@foo-VirtualBox:~/root/microservices/billing$ 

can you provide more information here: https://github.com/psf/black/issues/1180

I haven't been able to reproduce at all, if you could get a reproduction using docker that would be great

1c020c3d32ebf0cd008271462b6bbc12a77db2d9 appears to be the commit which added fF and sS -- from that it looks like maybe something to do with skipped / failed tests which weren't failing as a result of calling the test function? unclear :S

can you provide the test code which is failing?

I meant for a helper for the bottom half and don't use parametrize or an if statement

First off, I understand we appear to have gotten off on the wrong foot, please do not take my comments personally and I hope that we can work amicably now and in the future.

if you consult the README it gives an explanation of the goal this tool targets, handling architecture is not one of them since that's already solved by the vanilla tools

I do not have access to non-x86_64 and therefore it is prohibitively difficult for me to test against and downright frustrating to attempt to write code targetting it. I am not gifted with a rack of arm / Z / ppc / etc. hosts which I can use to test. And unless they're exposing actual bugs in the implementation it's not worth the greenhouse gasses, effort, or even the discussion.

I closed this issue because I don't care about the outcome of it, I have no intention myself to work on it and it doesn't affect the correctness of the tool. And that the goal of the tool is to handle the ambiguity of linux_x86_64 (even though it may work fine on other architectures / platforms)

If you can point out where this is a valid problem I'll reopen, but an exotic architecture test failure (in which the actual functionality probably actually works just fine) is not a helpful issue. I'd be especially amenable if you lead with a useful patch / etc. to help work towards it. I'm constantly bombarded with packagers which don't put in basic effort to try and solve problems themselves / improve the ecosystem :( Please understand this is free software and apologies if this looks personal

plus it would potentially break this which works today:

CASES = (1, 23, 2, 4)

@pytest.mark.parametrize('x', CASES, ids=string.ascii_letters[:len(CASES)])
def test(x):
    pass

$ pytest t.py -v
============================= test session starts ==============================
platform linux -- Python 3.6.8, pytest-5.3.1, py-1.8.0, pluggy-0.13.1 -- /tmp/x/venv/bin/python3
cachedir: .pytest_cache
rootdir: /tmp/x
collected 4 items                                                              

t.py::test[a] PASSED                                                     [ 25%]
t.py::test[b] PASSED                                                     [ 50%]
t.py::test[c] PASSED                                                     [ 75%]
t.py::test[d] PASSED                                                     [100%]

============================== 4 passed in 0.01s ===============================

oh I see what you're proposing -- I'm still -1 on what you're proposing, the type for the ids function is already complicated enough to understand as it is -- plus you can accomplish this by passing the .format function directly

while it would be possible, it would increase the complexity of parametrize further than it already is and (imo) with not much benefit.

open to hear what the other maintainers say but my leaning is that implementing and explaining this nuance of ids in docs would be pretty difficult and the small benefit in this one case would not out weigh the maintenance

An improvement seems more adequate here.

I believe you're looking for idfn http://doc.pytest.org/en/latest/example/parametrize.html#different-options-for-test-ids

minor thing, would be a useful improvement:

class C(six.with_metaclass(abc.ABCMeta, object)): pass

afaik it works all the way back to pip 1.4 (2013)

upper bounding the version is not a maintainable approach to python packaging so I won't do that (usually a new release works just fine)

this appears to be the main function movement, would you like to take a stab at a patch?

that said, if you want this, send a patch and I'll consider it

Packaged at https://build.opensuse.org/package/show/home:jayvdb:py-new/python-pip-custom-platform

There are a lot of failures in test_platform_linux due to different arch, e.g. on ppc

[  119s] __________________________ test_platform_linux[case7] __________________________
[  119s] 
[  119s] mock_distro = <MagicMock name='distro' id='140736209194344'>
[  119s] mock_platform = <MagicMock name='platform' id='140736209215048'>
[  119s] case = SystemTestCase(docker_image='base/archlinux', mock_id='arch', mock_version='', expected_platform_name='linux_x86_64', setup_script=('pacman -Syy >&2', 'pacman -S --noconfirm python python-pip >&2'))
[  119s] 
[  119s]     @pytest.mark.parametrize('case', SYSTEM_TESTCASES)
[  119s]     @mock.patch('pip_custom_platform.default_platform.platform')
[  119s]     @mock.patch('pip_custom_platform.default_platform.distro')
[  119s]     def test_platform_linux(mock_distro, mock_platform, case):
[  119s]         mock_distro.id.return_value = case.mock_id
[  119s]         mock_distro.version.return_value = case.mock_version
[  119s]         mock_platform.system.return_value = 'Linux'
[  119s]         mock_platform.machine.return_value = 'x86_64'
[  119s] >       assert default_platform_name() == case.expected_platform_name
[  119s] E       AssertionError: assert 'linux_ppc64le' == 'linux_x86_64'
[  119s] E         - linux_ppc64le
[  119s] E         + linux_x86_64

On s390x

[   66s] E       AssertionError: assert 'linux_s390x' == 'linux_x86_64'
[   66s] E         - linux_s390x
[   66s] E         + linux_x86_64

I expect this only needs a minor fix in the tests, or even skip it on non-Intel platforms if that case is intel specific.

fwiw, pymonkey is passing all tests on all openSUSE current platforms (except armv7l not yet built) https://build.opensuse.org/package/show/home:jayvdb:py-new/python-pymonkey

yeah there's no intention to test on anything other than x86_64 -- it does work on other platforms (and macos even and probably windows) but it's not worth the effort to test there

I'd rather see the assertion as a helper function than a stringly typed if statement -- no need for duplication and it's very clear the execution path

sound fine! I don't expect any to be mocking lru_cache so this should be mostly good -- it will require a --py38-plus option but that's no big deal

I tend to try and avoid logic in tests, I'd probably write this as two separate tests instead of this

tests should be as simple as possible for the programmer to read

here's a blog post I often link on this subject (a little more severe of a case there, but still the same sentiment): https://testing.googleblog.com/2014/07/testing-on-toilet-dont-put-logic-in.html

looks like your branch is accidentally based on master but targetting features -- could you rebase on top of features?

should be able to

git rebase -i upstream/features

and then remove any commits which aren't yours

(let me know and I can do this for you and push to your branch)

imo there should be one obvious way to do it, having both apis seems not great (when .match(...) already does what you're looking for)

woohoo, upstream added musl binaries, I'll take a stab at making this work :)

but basically, two plugins are monkeypatching .parent in different ways causing a conflict

ah you don't even have bandit, it must be one of click-best-practices, click-launch-uses-literal, click-option-check, or flake8-flask

I can't find the source for click-launch-uses-literal or click-option-check but suspect those two (the others look fine)

It has not yet -- if you upgrade the other conflicting package (I believe it was bandit?) it should resolve

I don't believe I have insulted intelligence anywhere? If I have please point it out and I will correct it

I misunderstood the script as running pip install --upgrade inside the pre-commit envs and after a second read noticed it was a different pip and deleted the comment, it's still using private implementation detail so I would suggest you don't do that. the "public"ish interfaces are in pre_commit.clientlib only

that script is terrifying, the environments inside the pre-commit cache are intended to be implementation detail and immutable -- please don;t do that you're asking for all sorts of trouble

@jayvdb if you're packaging this you probably want https://github.com/asottile/hecate/commit/bbec887f69f7cba9369051941fdbd8b48902ac14 as well

In my continued quest to single-source the versions of linters and formatters between pre-commit and my Python virtual environment (see #1233 and https://github.com/pre-commit/pre-commit/issues/945#issuecomment-563978549), I tried repository local hooks as suggested by #945. It works well, but I ended up with a config like:

  - repo: local
    hooks:
      - id: black
        name: black
        entry: black
        language: system
        types: [python]
      - id: flake8
        name: flake8
        entry: flake8
        language: system
        types: [python]
      - id: pydocstyle
        name: pydocstyle
        entry: pydocstyle
        language: system
        types: [python]

The repetition of id, name, and entry bugs me. 😉

Could name and entry default to the value of id?

repo: local and language: system both are escape hatches and not the supported golden path to use tools

the metadata for repo: local is the full .pre-commit-hooks.yaml and is meant to be very explicit

so no, I won't do this -- but thank you for the issue!

If you want a supported configuration, use this with no repetition:

repos:
-   repo: https://github.com/psf/black
    rev: 19.10b0
    hooks:
    -   id: black
-   repo: https://gitlab.com/pycqa/flake8
    rev: 3.7.9
    hooks:
    -   id: flake8
-   repo: https://github.com/pycqa/pydocstyle
    rev: 5.0.1
    hooks:
    -   id: pydocstyle

Resolves #10 Obsoletes #9

none of my projects are missing LICENSE in sdist, you're just confused how setuptools works -- here's my oldest uploaded and still maintained package:

$ tar --list -f all_repos_depends-0.0.1.tar.gz | grep LICENSE
all_repos_depends-0.0.1/LICENSE

and it has NO MANIFEST.in so please stop pushing this junk file on maintainers <3

https://github.com/advisories/GHSA-h9rv-jmmf-4pgx

not sure the right way to resolve this, I tried clicking the github button to autoresolve and it did nothing, so I rm package-lock.json && npm install'd

https://github.com/advisories/GHSA-h9rv-jmmf-4pgx

not sure the right way to resolve this, I tried clicking the github button to autoresolve and it did nothing, so I rm package-lock.json && npm install'd

flake8-comprehensions is a lovely plugin to warn about inefficient creation of and operations on collections - and each of the warnings suggests a simple rewrite rule to resolve them.

I'm not sure if this is really in scope for pyupgrade, but it's similar enough to the existing literals/comprehensions functionality that I thought it was worth suggesting.

This is a dupe of #31 and out of scope I'm afraid

dict(**...) might in the future be rewritten to {**...} but generically rewriting dict(...) isn't quite in the spirit

I hope you understand where I'm coming from -- I don't want to add this junk file to our repository that we don't use and you don't need. Our tags are correct and it works fine to use the github tgz.

venv-update frequently breaks with the latest pip (kinda by design, it has to monkeypatch pip to work) -- I wouldn't be surprised if it's currently broken and would appreciate attempts to fix it. In the past we've flipped between marking "latest pip" as expected failure in .travis.yml -- I happen to know there's some pretty big refactors happening in pip right now (that are about to break a bunch more things like last time)

this package (ephemeral-port-reserve) has been pretty stable and hasn't seen updates in quite some time -- (after all, it's dead simple and really doesn't need any maintenance), I don't think it would be much of a maintenance concern