Every one of the projects in this repository is available at the canonical
URL git://git.madduck.net/madduck/pub/<projectpath> — see
each project's metadata for the exact URL.
All patches and comments are welcome. Please squash your changes to logical
commits before using git-format-patch and git-send-email to
patches@git.madduck.net.
If you'd read over the Git project's submission guidelines and adhered to them,
I'd be especially grateful.
Cooper Lees [Sun, 17 May 2020 19:18:49 +0000 (12:18 -0700)]
Add black-primer unittests (#1426)
* Add black-primer unittests
- Get this tool covered with some decent unittests for all unittests wins
- Have a CLI and lib test class
- Import it from `test_black.py` so we always run tests
- Revert typing asyncio.Queue as Queue[str] so we can work in 3.6
- **mypy**: Until black > 3.6 disallow_any_generics=False for primer code
Test:
- Run tests: `coverage run tests/test_primer.py` or `coverage run -m unittest`
```
(b) cooper-mbp1:black cooper$ coverage report
Name Stmts Miss Cover
---------------------------------------------
src/black_primer/cli.py 49 8 84%
src/black_primer/lib.py 148 28 81%
tests/test_primer.py 114 1 99%
---------------------------------------------
TOTAL 311 37 88%
```
* Use ProactorEventLoop for Windows + fix false path for Linux
* Set Windows to use ProactorEventLoop in to benefit all callers
* sys.platform seems to not having the loop applied - So type ignore and use platform.system() gate
* Have each test loop correctly set to ProactorEventLoop on Windows for < 3.8 too
Cooper Lees [Sun, 17 May 2020 00:36:20 +0000 (17:36 -0700)]
Add primer CI tool 🏴 (#1402)
* Add primer CI tool 💩
- Run in PATH `black` binary on configured projects
- Can set wether we expect changes or not per project
- Can set what python versions are supported for a project
- if `long_checkout` True project will not be ran on CI
Will add to CI after I finish unit tests to avoid silly bugs I'm sure I have 🤪
Tests:
- Manual Run - Will add unit tests if people think it will be useful
- Output:
```shell
(b) cooper-mbp1:black cooper$ time /tmp/b/bin/black-primer -k -w /tmp/cooper_primer_1
[2020-05-10 08:48:25,696] INFO: 4 projects to run black over (lib.py:212)
[2020-05-10 08:48:25,697] INFO: Skipping aioexabgp as it's disabled via config (lib.py:166)
[2020-05-10 08:48:25,699] INFO: Skipping bandersnatch as it's disabled via config (lib.py:166)
[2020-05-10 08:48:28,676] INFO: Analyzing results (lib.py:225)
-- primer results 📊 --
2 / 4 succeeded (50.0%) ✅
0 / 4 FAILED (0.0%) 💩
- 2 projects Disabled by config
- 0 projects skipped due to Python Version
- 0 skipped due to long checkout
real 0m3.304s
user 0m9.529s
sys 0m1.019s
```
- ls of /tmp/cooper_primer_1
```
(b) cooper-mbp1:black cooper$ ls -lh /tmp/cooper_primer_1
total 0
drwxr-xr-x 21 cooper wheel 672B May 10 08:48 attrs
drwxr-xr-x 14 cooper wheel 448B May 10 08:48 flake8-bugbear
```
* Address mypy 3.6 type errors
- Don't use asyncio.run() ... go back to the past :P
- Refactor results into a named tuple of two dicts to avoid typing nightmare
- Fix some variable names
- Fix bug with rebase logic in git_checkout_or_rebase
* Prettier the JSON config file for primer
* Delete projects when finished, move dir to be timestamped + shallow copy
* Re-enable disabled projects post @JelleZijlstra's docstring fix
* Workaround for future annotations until someone tells me the correct fix
Richard Si [Sat, 16 May 2020 20:22:46 +0000 (16:22 -0400)]
Document git's ignore-revs-file feature (#1419)
* Document git's ignore-revs-file feature
A long-standing counterargument against moving to automated code formatters
like Black is that the migration will clutter up the output of git blame.
This used to be a valid argument, but not anymore. Since git version 2.23,
git natively supports ignoring revisions in blame with the --ignore-rev
and --ignore-revs-file options.
This isn't documented in the Black documentation. It should be as it would
put old projects wanting to migrate to Black at ease since blame won't
be ruined.
* Add links so people can +1 on --ignore-revs-file support
* Fix wording
'Counterargument' was the wrong word since it means an objection to an objection. 'Argument' is the proper word I was looking for.
Richard Si [Sat, 16 May 2020 09:21:31 +0000 (05:21 -0400)]
Expand docs about slice formatting (#1418)
Black will apply no spaces around ':' operators for 'simple' expresssions
, but will apply extra space around ':' operators for 'complex' expressions.
Black treats anything more than variable names as 'complex', but this isn't
noted in the Black documentation. Which leads to a few issues on the GitHub
issue tracker that all report inconsistent spacing around ':' operators.
Cooper Lees [Fri, 8 May 2020 15:50:50 +0000 (08:50 -0700)]
Refactor black into packages in src/ dir (#1376)
- Move black.py to src/black/__init__.py
- Have setuptools_scm make src/_black_version.py and exclude from git
- Move blackd.py to src/blackd/__init__.py
- Move blib2to3/ to src/
- Update `setup.py`
- Update unittests to pass
- Mostly path fixing + resolving
- Update CI
- pre-commit config
- appveyor + travis
Tested on my mac with python 3.7.5 via:
```
python3 -m venv /tmp/tb3
/tmp/tb3/bin/pip install --upgrade setuptools pip coverage pre-commit
/tmp/tb2/bin/pip install ~/repos/black/
cd ~/repos/black/
/tmp/tb2/bin/coverage run tests/test_black.py
/tmp/tb3/bin/pre-commit run -a
/tmp/tb3/bin/black --help
/tmp/tb3/bin/black ~/repos/ptr/ptr.py
```
shaoran [Fri, 8 May 2020 15:42:19 +0000 (17:42 +0200)]
Adding documentation to the README for import errors in vim (#1317)
* Adding documentation to the README for import errors in vim
I had the same issue as psf/black#1148 and have been searching for a
solution to this. I realized that you cannot fix it by change anything
in the code, but by re-compiling the C extensions of regex and
typed-ast. Installing this packages from the tarballs solves the
problem.
* Fixing a bad copy&paste
Co-Authored-By: Hugo van Kemenade <hugovk@users.noreply.github.com>
* chore: changed made by pre-commit
* chore: better way of dealing with non-binary installs
* chore: adding vim cache files to the ignore list
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
Cooper Lees [Fri, 8 May 2020 14:29:53 +0000 (07:29 -0700)]
Update CHANGELOG with some PRs merged (#1391)
* Update CHANGELOG with some PRs merged
- Add section for vim plugin
- Add vim plugin now prefering virtualenv
- Add py3 tagged wheels
* packges
* Update CHANGES.md _Black_
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
* Update CHANGES.md Vim
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com> Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com> Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
Richard Si [Fri, 8 May 2020 14:26:29 +0000 (10:26 -0400)]
Add Black compatible configurations in documentation (#1366 & #1205) (#1371)
* Add Black compatible configs in docs ( #1366 & #1205)
When users of Black are starting a new project or are adding Black to their
existing projects, they will usually have to config their existing tools like
flake8 to be compatible with Black. Usually, these configs are the same across
different projects. Yet, there isn't any consolidated infomation on what configs
are compatible. Leaving users of Black to dig out any infomation they can find
in README.md.
* Fix a bad max-line-length value
* Clean up pylint's configs
* Add explanations for each configurations
Copying and pasting code without understanding it is a bad idea. This goes the same
for users copying and pasting configurations.
* Capitalize Pylint
* Link from the README
* Fix the isort configuration
I referenced the wrong source. I used a pesonal configuration, not a pure Black-
compatible configuration.
* Improve the config explanations
The explanation for the isort configuration was pretty bad. After having fixed the
configuration (see commit 01c55d1), improving the its explanation was necessary to
make it more user-friendly and understandable. Also added fenced code blocks of the
raw configuration options so the explanations make sense.
Allan Simon [Fri, 8 May 2020 13:46:07 +0000 (15:46 +0200)]
permits black to run in AWS Lambda: (#1141)
AWS Lambda and some other virtualized environment may not permit access
to /dev/shm on Linux and as such, trying to use ProcessPoolExecutor will
fail.
As using parallelism is only a 'nice to have' feature of black, if it fails
we gracefully fallback to a monoprocess implementation, which permits black
to finish normally.
David Lukes [Fri, 8 May 2020 13:13:54 +0000 (15:13 +0200)]
Make sure sys._base_executable is sane in Vim plugin (#1380)
The `venv` module relies on `sys._base_executable` to determine the
Python executable to run, but with recent versions of Vim, this is set
to the `vim` executable. A possible workaround is to just override it,
since the `black` plugin already overrides `sys.executable` (possibly
for similar reasons?) anyway.
Alex Vandiver [Fri, 8 May 2020 13:08:15 +0000 (06:08 -0700)]
Re-indent the contents of docstrings (#1053)
* Re-indent the contents of docstrings when indentation changes
Keeping the contents of docstrings completely unchanged when
re-indenting (from 2-space intents to 4, for example) can cause
incorrect docstring indentation:
```
class MyClass:
"""Multiline
class docstring
"""
def method(self):
"""Multiline
method docstring
"""
pass
```
...becomes:
```
class MyClass:
"""Multiline
class docstring
"""
This uses the PEP 257 algorithm for determining docstring indentation,
and adjusts the contents of docstrings to match their new indentation
after `black` is applied.
A small normalization is necessary to `assert_equivalent` because the
trees are technically no longer precisely equivalent -- some constant
strings have changed. When comparing two ASTs, whitespace after
newlines within constant strings is thus folded into a single space.
Co-authored-by: Luka Zakrajšek <luka@bancek.net>
* Extract the inner `_v` method to decrease complexity
This reduces the cyclomatic complexity to a level that makes flake8 happy.
* Blacken blib2to3's docstring which had an over-indent
Co-authored-by: Luka Zakrajšek <luka@bancek.net> Co-authored-by: Zsolt Dollenstein <zsol.zsol@gmail.com>
Bryan Bugyi [Fri, 8 May 2020 12:56:21 +0000 (08:56 -0400)]
Improve String Handling (#1132)
This pull request's main intention is to wraps long strings (as requested by #182); however, it also provides better string handling in general and, in doing so, closes the following issues:
Change exit code to 2 when config file doesn't exist (#1361)
Fixes #1360, where an invalid config file causes a return/exit code of 1. This
change means this case is caught earlier, treated like any other bad
parameters, and results in an exit code of 2.
`split("\n")` includes a final empty element `""` if the final line
ends with `\n` (as it should for POSIX-compliant text files), which
then became an extra `"\n"`.
`splitlines()` solves that, but there's a caveat, as it will split
on other types of line breaks too (like `\r`), which may not be
desired.
Cooper Lees [Wed, 4 Mar 2020 15:40:48 +0000 (15:40 +0000)]
Split out Change Log (#1117)
* Split out Change Log
- Move to CHANGES.md to allow bots to see changes
- MANIFEST.in already includes *.md so CHANGES.md will be included
- THis maintains format but the change log will now be after acknowledgements
- This also ensure this gets added to pypi.org via setup.py function
Paul Ganssle [Tue, 3 Mar 2020 12:00:52 +0000 (07:00 -0500)]
Notify users of missing Python lazily (#1210)
Currently this message shows up with no context prior to the start of
Vim. By changing this to a lazy message, the user will only be notified
of a problem with the Black plugin when they are attempting to use the
Black plugin.
Fix unstable formatting with some `# type: ignore`s (#1113)
`type: ignore` shouldn't block collapsing a line, since it will still
apply fine to the merged line. This prevents an issue where a reformat
causes it to shift lines and then be merged on a subsequent pass.
There is a downside to this, which is that it can cause a `type:
ignore` to apply to more code than was originally intended. There
might be a way to apply this in a more limited situation, but I'm not
sure what it is.
projects / etc / vim.git / log