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 [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.
Stefan Wimmer [Thu, 11 Mar 2021 14:41:06 +0000 (15:41 +0100)]
- migrate to new Colortemplate v2.1 syntax
- indentation
- make light & dark colours variations more similar with one specific colour as origin
- add SignColumn
- add bold to CursorLine only
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.
Richard Si [Sun, 14 Feb 2021 15:23:47 +0000 (10:23 -0500)]
Fix duplication of checks on internal PRs (#1986)
Internal PRs (that come from branches of psf/black) match both the push
and pull_request events. This leads to a duplication of test, lint, etc.
checks on such PRs. Not only is it a waste of resources, it makes the
Status Checks UI more frustrating to go through.
Patch taken from:
https://github.community/t/duplicate-checks-on-push-and-pull-request-simultaneous-event/18012
James Addison [Thu, 11 Feb 2021 20:11:42 +0000 (20:11 +0000)]
Stability fixup: interaction between newlines and comments (#1975)
* Add test case to illustrate the issue
* Accept carriage returns as valid separators while enumerating comments
Without this acceptance, escaped multi-line statments that use carriage returns will not be counted into the 'ignored_lines' variable since the emitted line values will end with a CR and not an escape character. That leads to comments associated with the line being incorrectly labeled with the STANDALONE_COMMENT type, affecting comment placement and line space management.
Richard Si [Fri, 5 Feb 2021 04:10:45 +0000 (23:10 -0500)]
Update prettier in pre-commit config (#1966)
With older versions of prettier, when the hook failed a bunch of
"[error] No parser could be inferred for file: {PATH}" error lines
showed up because of lack of support of a flag that pre-commit
passes for us by default. It made figuring out why the prettier hook
failed annoying.
Oliver Newman [Wed, 27 Jan 2021 17:36:21 +0000 (12:36 -0500)]
Update example exclude to match only files in root (#1861)
* Update example exclude to match only files in root
The `exclude` section of the example `pyproject.toml` file didn't work
as expected. It claimed to exclude matched files only in the project
root, but it actually excluded matched files at any directory level
within the project. We can address this by prepending `^/` to the regex
to ensure that it only matches files in the project root.
See https://github.com/psf/black/issues/1473#issuecomment-740008873 for
explanation.
Jon Dufresne [Thu, 31 Dec 2020 17:09:07 +0000 (09:09 -0800)]
Add pyi file support to .pre-commit-hooks.yaml (#1875)
Since pre-commit 2.9.0 (2020-11-21), the types_or key can be used to
match multiple disparate file types. For more upstream details, see:
https://github.com/pre-commit/pre-commit/issues/607
Add the minimum_pre_commit_version to require pre-commit 2.9.0+.
Richard Si [Mon, 28 Dec 2020 02:38:11 +0000 (21:38 -0500)]
Bump mypy to 0.780 in pre-commit config (#1887)
To avoid hitting a mypy bug causes pre-commit to always fail on CPython
3.9. Even though it's still an outdated version, the bug effectively
blocks development on CPython 3.9 so that's why this commit exists
instead of waiting for cooperlees to finish his bump to 0.790 PR.
Also this fixes primer to ensure it always raises CalledProcessError
with an int error code. I stole the patch from cooperlees's mypy bump
PR.
It's funny how mypy 0.790 is already asked for in our
Pipfile.lock file, but oh well mypy is probably more commonly run
through pre-commit than standalone I guess.
Oh and if you're curious why the bug doesn't up on CPython 3.8 or lower:
there was some subscription AST changes in CPython 3.9.
Justin Prieto [Mon, 9 Nov 2020 19:58:23 +0000 (14:58 -0500)]
Correctly handle inline tabs in docstrings (#1810)
The `fix_docstring` function expanded all tabs, which caused a
difference in the AST representation when those tabs were inline and not
leading. This changes the function to only expand leading tabs so inline
tabs are preserved.
Richard Si [Sun, 1 Nov 2020 21:17:23 +0000 (16:17 -0500)]
Automatically build and upload binaries on release (#1743)
This commit adds a new GitHub Actions workflow that builds self-contained
binaries / executables and uploads them as release assets to the triggering
release. Publishing a release, drafting one doesn't count, will trigger this
workflow.
I personally used GitHub Actions only because it's the CI/CD platform(?)
I am familiar with. Only Windows and Linux binaries are supported since
I don't have any systems running Mac OS.
For Linux, I had originally planned to use the manylinux2010 docker image
the PyPA provides for highly compatible wheel building, but unfortunately
it wasn't feasible due to GitHub Actions and PyInstaller incompatibilities.
As a stopgap the oldest versions of Linux and Windows are used although
Windows Server 2019 isn't that old nor is Ubuntu 16.04! I guess someone
(maybe me) could work out something else if compatibility is big problem.
A few things you should know about the workflow:
- You don't need to set the `GITHUB_TOKEN` secret as it is automatically
provided by GitHub.
- matrix.pathsep is used because PyInstaller configuration's format is OS
dependent for some reason ...
Also it's worth mentioning that Black once had Travis CI and AppVeyor
configuration that did the same thing as this commit. They were committed
in mid 2018 and worked (somewhat) well. Eventually we stopped using AppVeyor
and the refactor to packages broke the Travis CI config. This commit
replaces the still existing and broken Travis CI config wholesale.
Co-authored-by: Anders Fredrik Kiær <31612826+anders-kiaer@users.noreply.github.com>
- Anders told me that I could get the release asset upload URL directly
from the github.event.release payload. I originally planned to use
bruceadams/get-release to get such URL.
projects / etc / vim.git / log