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.
Kaleb Barrett [Fri, 7 May 2021 12:54:21 +0000 (07:54 -0500)]
Do not use gitignore if explicitly passing excludes (#2170)
Closes #2164.
Changes behavior of how .gitignore is handled. With this change, the rules in .gitignore are only used as a fallback if no exclusion rule is explicitly passed on the command line or in pyproject.toml. Previously they were used regardless if explicit exclusion rules were specified, preventing any overriding of .gitignore rules.
Those that depend only on .gitignore for their exclusion rules will not be affected. Those that use both .gitignore and exclude will find that exclude will act more like actually specifying exclude and not just another extra-excludes. If the previous behavior was desired, they should move their rules from exclude to extra-excludes.
Shota Ray Imaki [Thu, 6 May 2021 02:25:43 +0000 (11:25 +0900)]
Simplify GitHub Action entrypoint (#2119)
This commit simplifies entrypoint.sh for GitHub Actions by removing
duplication of args and black_args (cf. #1909).
The reason why #1909 uses the input id black_args is to avoid an overlap
with args, but this naming seems redundant. So let me suggest option
and src, which are consistent with CLI. Backward compatibility is
guaranteed; Users can still use black_args as well.
Commit history pre-merge:
* Simplify GitHub Action entrypoint (#1909)
* Fix prettier
* Emit a warning message when `black_args` is used
This deprecation should be visible in GitHub Action's UI now.
Co-authored-by: Shota Ray Imaki <shota.imaki.0801@gmail.com> Co-authored-by: Richard Si <63936253+ichard26@users.noreply.github.com>
Cooper Lees [Wed, 5 May 2021 15:33:23 +0000 (08:33 -0700)]
Enable ` --experimental-string-processing` on most primer projects (#2184)
* Enable ` --experimental-string-processing` on all primer projects
- We want to make this default so need to test it more
- Fixed splat/star bug in extending black args for each project
Richard Si [Tue, 4 May 2021 08:47:59 +0000 (04:47 -0400)]
Drop Travis CI and migrate Coveralls (#2186)
Travis CI for Open Source is shutting down in a few weeks so the queue
for jobs is insane due to lower resources. I'm 99.99% sure we don't need
it as our Test, Lint, Docs, Upload / Package, Primer, and Fuzz workflows
are all on GitHub Actions. So even though we *can* migrate to the .com
version with its 1000 free Linux minutes(?), I don't think we need to.
more information here:
- https://blog.travis-ci.com/oss-announcement
- https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing
- https://docs.travis-ci.com/user/migrate/open-source-repository-migration
This commit does the following:
- delete the Travis CI configuration
- add to the GHA test workflows so coverage continues to be recorded
- tweaked coverage configuration so this wouldn't break
- remove any references to Travis CI in the docs (i.e. readme + sphinx
docs)
Regarding the Travis CI to GitHub Actions Coveralls transition, the
official action doesn't support the coverage files produced by coverage.py
unfornately. Also no, I don't really know what I am doing so don't @ me
if this breaks :p (well you can, but don't expect me to be THAT useful).
The Coveralls setup has two downfalls AFAIK:
- Only Linux runs are used because AndreMiras/coveralls-python-action
only supports Linux. Although this isn't a big issue since the Travis
Coveralls configuration only used Linux data too.
- Pull requests from an internal branch (i.e. one on psf/black) will be
marked as a push coverage build by Coveralls since our anti-duplicate-
workflows system runs under the push even for such cases.
Richard Si [Tue, 4 May 2021 08:46:46 +0000 (04:46 -0400)]
Detect `'@' dotted_name '(' ')' NEWLINE` as a simple decorator (#2182)
Previously the RELAXED_DECORATOR detection would be falsely True on that
example. The problem was that an argument-less parentheses pair didn't
pass the `is_simple_decorator_trailer` check even it should. OTOH a
parentheses pair containing an argument or more passed as expected.
Cooper Lees [Mon, 3 May 2021 21:58:17 +0000 (14:58 -0700)]
primer: Renable pandas (#2185)
- It no longer crashes black so we should test on it's code
- Update django reason to name the file causing error
- Seems it has a syntax error on purpose
Cooper Lees [Wed, 28 Apr 2021 03:10:44 +0000 (20:10 -0700)]
Add automatic version tagging to Docker CI Pushes (#2132)
* Add automatic version tagging to Docker Uploads
- If the git comment has a tag, set that on the docker images pushed
- If we don't have a tag, we just set `latest_non_release`
Richard Si [Mon, 26 Apr 2021 20:26:43 +0000 (16:26 -0400)]
Stop stripping parens in even more illegal spots (#2148)
We're only fixing them so fuzzers don't yell at us when we break "valid"
code. I mean "valid" because some of the examples aren't even accepted by
Python.
Richard Si [Mon, 26 Apr 2021 15:28:42 +0000 (11:28 -0400)]
Don't strip parens in assert / return with assign expr (#2143)
Black would previously strip the parenthesis away from statements like this these ones:
assert (spam := 12 + 1)
return (cheese := 1 - 12)
Which happens to be invalid code. Now before making the parenthesis invisible, Black
checks if the assignment expression's parent is an assert stamtment, aborting if True.
Raise, yield, and await are already handled fine.
I added a bunch of test cases from the PEP defining asssignment expressions (PEP 572).
Cooper Lees [Sun, 25 Apr 2021 21:51:13 +0000 (14:51 -0700)]
Docker CI: Add missed Checkout step (#2128)
- Reading my error others hit it by forgetting this Checkoutstep too so trying the fix
- e.g. https://github.com/docker/build-push-action/issues/179
- Makes sense it's needed
Work around stability errors due to optional trailing commas (#2126)
Optional trailing commas put by Black become magic trailing commas on another
pass of the tool. Since they are influencing formatting around optional
parentheses, on rare occasions the tool changes its mind in terms of putting
parentheses or not.
Ideally this would never be the case but sadly the decision to put optional
parentheses or not (which looks at pre-existing "magic" trailing commas) is
happening around the same time as the decision to put an optional trailing
comma. Untangling the two proved to be impractically difficult.
This shameful workaround uses the fact that the formatting instability
introduced by magic trailing commas is deterministic: if the optional trailing
comma becoming a pre-existing "magic" trailing comma changes formatting, the
second pass becomes stable since there is no variable factor anymore on pass 3,
4, and so on.
For most files, this will introduce no performance penalty since `--safe` is
already re-formatting everything twice to ensure formatting stability. We're
using this result and if all's good, the behavior is equivalent. If there is
a difference, we treat the second result as the binding one, and check its
sanity again.
Cooper Lees [Thu, 8 Apr 2021 04:13:11 +0000 (21:13 -0700)]
Add `black` Dockerfile (#1916)
* Add `black` Dockerfile
- Build a `black` container based on python3-slim
- Test: `docker build --network-host --tag black .`
```console
cooper-mbp1:black cooper$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
black latest 0c7636402ac2 4 seconds ago 332MB
```
Addresses part of #1914
* Build with colorama + d extra installs - Adds ~9mb
* Combine all build commands in 1 run
- Combine the commands all into 1 RUN to down the size
- Get to 65.98 MB image size now: https://hub.docker.com/repository/docker/cooperlees/black/tags?page=1&ordering=last_updated
* Add rm -r of /var/lib/apt/lists/* + save 10mb down to 55mb
Richard Si [Thu, 1 Apr 2021 21:24:18 +0000 (17:24 -0400)]
Push contributors to use Next PR Number (#2080)
This is a tool of my own making. Right now our requirement to have the
PR number in the changelog entry is pretty painful / annoying since
the contributor either has to guess or add the # retroactively after
the PR creation. This tool should make it way less painful by making
it simple to get your PR number beforehand.
At the user level, a TOML config can be specified in the following locations:
* Windows: ~\.black
* Unix-like: $XDG_CONFIG_HOME/black (~/.config/black fallback)
Instead of changing env vars for the entire black-primer process, they
are now changed only for the black subprocess, using a tmpdir.
Richard Si [Wed, 24 Mar 2021 23:38:07 +0000 (19:38 -0400)]
Add entry for `--extend-exclude` in the right place (#2061)
The PR author added the changelog entry for their `extend-exclude` addition
in `docs/change_log.md` which is understandable but incorrect as it will be
overwritten since it's autogenerated from the readme.
Cooper Lees [Sun, 21 Mar 2021 20:05:24 +0000 (13:05 -0700)]
Add a GitHub CHANGELOG/News Check (#2057)
- Run grep to see commit has a line mentioning it to CHANGES.md
- Also add a label to disable this being required for PRs that don't need a change entry
Jairo Llopis [Thu, 18 Mar 2021 15:14:15 +0000 (15:14 +0000)]
Recommend B950 + 88 char limit instead of 80 (#2050)
[The section about line length][1] was contradictory.
On one side, it said:
> Black will try to respect that [line length limit]. However, sometimes it won't be able to without breaking other rules. In those rare cases, auto-formatted code will exceed your allotted limit.
So black doesn't guarantee that your code is formatted at 88 chars, even when configured with `--line-length=88` (default). Black uses this limit as a "hint" more than a "rule".
OTOH, it also said:
> If you're using Flake8, you can bump max-line-length to 88 and forget about it. Alternatively, use Bugbear's B950 warning instead of E501 and keep the max line length at 80 which you are probably already using.
But that's not true. You can't "forget about it" because Black sometimes won't respect the limit. Both E501 at 88 and B950 at 80 behave the same: linter error at 89+ length. So, if Black happens to decide that a line of code is better at 90 characters that some other fancy style, you land on a unlucky situation where both tools will fight.
So, AFAICS, the best way to align flake8 and black is to:
1. Use flake8-bugbear
2. Enable B950
3. Disable E501
4. Set `max-line-length = 88`
This way, we also tell flake8 that 88 limit is a "hint" and not a "rule". The real rule will be 88 + 10%. If black decides that a line fits better in 97 characters than in 88 + some formatting, _that_ probably means your code has a real problem.
To avoid further confusion, I change the official recommendation here.
Indicate that a final newline was added in --diff (#1897) (#1897)
Fixes: #1662
Work-around for https://bugs.python.org/issue2142
The test has to slightly mess with its input data, because the utility
functions default to ensuring the test data has a final newline, which
defeats the point of the test.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
James Addison [Sat, 20 Feb 2021 16:44:48 +0000 (16:44 +0000)]
fuzzer: add special-case for multi-line EOF TokenError (#1991)
* Add special-case for multi-line EOF TokenError under Python3.7
* Update conditional check to correspond to original issue description (and include issue hyperlink)
* Add warning and hint regarding replaying the fuzzer code generation
* Include code review suggestion (with modifications for this to follow)
Co-authored-by: Zac Hatfield-Dodds <zac.hatfield.dodds@gmail.com>
* Remove Python version check, since this issue does exist across more recent Python versions than 3.7
* Update explanatory comment
* Add clarification for potentially-ambiguous blib2to3 import
* Update explanatory comment
* Bring comment into consistent format with previous comment
* Revert "Add clarification for potentially-ambiguous blib2to3 import"
rht [Sun, 14 Feb 2021 15:32:29 +0000 (10:32 -0500)]
readme: Include Zulip in used-by section (#1987)
Zulip has recently formatted their code in Black and also set Black as a linter: https://github.com/zulip/zulip/pull/15662.
See also https://chat.zulip.org/#narrow/stream/2-general/topic/black.
projects / etc / vim.git / log