* Update CHANGES.md for 21.7b0 release
* move some changes to the right section
* another one
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
They seem to be used as test cases for a specific region of formatting
that was slow. Now performance testing is probably something end users
won't be needing to do, so this is an easy way of reducing the sdist
size sigificantly.
toml unfortunately has a lack of maintainership issue right now. It's
evident by the fact toml only supports TOML v0.5.0. TOML v1.0.0 has
been recently released and right now Black crashes hard on its usage.
tomli is a brand new parse only TOML library. It supports TOML
v1.0.0. Although TBH we're switching to this one mostly because
pip is doing the same.
*The upper bound was included at the library maintainer's request.
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
Co-authored-by: Taneli Hukkinen <3275109+hukkin@users.noreply.github.com>
Commit history before merge:
* Accept empty stdin (close#2337)
* Update tests/test_black.py
* Add changelog
* Assert Black reformats an empty string to an empty string (#2337) (#2346)
* fix
Click types have been moved to click repo itself. See pallets/click#1856
I've had some issues with typeshed types being outdated in another project
so might be good to avoid that here.
Commit history before merge:
* Get `click` types from main repo
* Fix mypy errors
* Require click v8 for type annotations
* Update Pipfile
This commit fixes parsing of the skip-string-normalization option in vim
plugin. Originally, the plugin read the string-normalization option,
which does not exist in help (--help) and it's not respected by black
on command line.
Commit history before merge:
* fix string normalization option in vim plugin
* fix string normalization option in vim plugin
* Finish and fix patch (thanks Matt Wozniski!)
FYI: this is totally the work and the comments below of Matt (AKA godlygeek)
This fixes two entirely different problems related to how pyproject.toml
files are handled by the vim plugin.
=== Problem #1 ===
The plugin fails to properly read boolean values from pyproject.toml.
For instance, if you create this pyproject.toml:
```
[tool.black]
quiet = true
```
the Black CLI is happy with it and runs without any messages, but the
:Black command provided by this plugin fails with:
```
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "<string>", line 102, in Black
File "<string>", line 150, in get_configs
File "<string>", line 150, in <dictcomp>
File "/usr/lib/python3.6/distutils/util.py", line 311, in strtobool
val = val.lower()
AttributeError: 'bool' object has no attribute 'lower'
```
That's because the value returned by the toml.load() is already a
bool, but the vim plugin incorrectly tries to convert it from a str to a bool.
The value returned by toml_config.get() was always being passed to
flag.cast(), which is a function that either converts a string to an
int or a string to a bool, depending on the flag. vim.eval()
returns integers and strings all as str, which is why we need the cast,
but that's the wrong thing to do for values that came from toml.load().
We should be applying the cast only to the return from vim.eval()
(since we know it always gives us a string), rather than casting the
value that toml.load() found - which is already the right type.
=== Problem #2 ===
The vim plugin fails to take the value for skip_string_normalization
from pyproject.toml. That's because it looks for a string_normalization
key instead of a skip_string_normalization key, thanks to this line
saying the name of the flag is string_normalization:
black/autoload/black.vim (line 25 in 05b54b8)
```
Flag(name="string_normalization", cast=strtobool),
```
and this dictcomp looking up each flag's name in the config dict:
black/autoload/black.vim (lines 148 to 151 in 05b54b8)
```
return {
flag.var_name: flag.cast(toml_config.get(flag.name, vim.eval(flag.vim_rc_name)))
for flag in FLAGS
}
```
For the second issue, I think I'd do a slightly different patch. I'd
keep the change to invert this flag's meaning and change its name that
this PR proposes, but I'd also change the handling of the
g:black_skip_string_normalization and g:black_string_normalization
variables to make it clear that g:black_skip_string_normalization is
the expected name, and g:black_string_normalization is only checked
when the expected name is unset, for backwards compatibility.
My proposed behavior is to check if g:black_skip_string_normalization
is defined and to define it if not, using the inverse of
g:black_string_normalization if that is set, and otherwise to the
default of 0. The Python code in autoload/black.vim runs later, and
will use the value of g:black_skip_string_normalization (and ignore
g:black_string_normalization; it will only be used to set
g:black_skip_string_normalization if it wasn't already set).
---
Co-authored-by: Matt Wozniski <mwozniski@bloomberg.net>
* Fix plugin/black.vim (need to up my vim game)
Co-authored-by: Matt Wozniski <godlygeek@gmail.com>
Co-authored-by: Richard Si <63936253+ichard26@users.noreply.github.com>
Co-authored-by: Matt Wozniski <mwozniski@bloomberg.net>
Co-authored-by: Matt Wozniski <godlygeek@gmail.com>
Commit history before merge:
* Find pyproject from vim relative to current file
* Merge remote-tracking branch 'upstream/main' into find-pyproject-vim
* Finish and fix this patch (thanks Matt Wozniski!)
Both the existing code and the proposed code are broken.
The vim.eval() call (whether it's vim.eval("@%") or
vim.eval("fnamemodify(getcwd(), ':t')) returns a string, and it passes
that string to find_pyproject_toml, which expects a sequence of strings,
not a single string, and - since a string is a sequence of single
character strings - it gets turned into a list of ridiculous paths. I
tested with a file called foo.py, and added a print(path_srcs) into
find_project_root, which printed out:
[
PosixPath('/home/matt/f'),
PosixPath('/home/matt/o'),
PosixPath('/home/matt/o'),
PosixPath('/home/matt'),
PosixPath('/home/matt/p'),
PosixPath('/home/matt/y')
]
This does work for an unnamed buffer, too - we wind up calling
black.find_pyproject_toml(("",)), and that winds up prepending the
working directory to any relative paths, so "" just gets turned into
the current working directory.
Note that find_pyproject_toml needs to be passed a 1-tuple, not a
list, because it requires something hashable (thanks to
functools.lru_cache being used)
Co-authored-by: Matt Wozniski <mwozniski@bloomberg.net>
* I forgot the CHANGELOG entry ... again
* I'm really bad at dealing with merge conflicts sometimes
* Be more correct describing search behaviour
Co-authored-by: Austin Glaser <austin.glaser@spacex.com>
Co-authored-by: Richard Si <63936253+ichard26@users.noreply.github.com>
Co-authored-by: Matt Wozniski <mwozniski@bloomberg.net>
* Add STDIN test to primer
- Check that out STDIN black support stays working
- Add asyncio.subprocess STDIN pip via communicate
- We just check we format python code from primer's `lib.py`
Fixes#2310
`black.strings.get_string_prefix` used to lowercase the extracted
prefix before returning it. This is wrong because 1) it ignores the
fact we should leave R prefixes alone because of MagicPython, and 2)
there is dedicated prefix casing handling code that fixes issue 1.
`.lower` is too naive.
This was originally fixed in 20.8b0, but was reintroduced since 21.4b0.
I also added proper prefix normalization for docstrings by using the
`black.strings.normalize_string_prefix` helper.
Some more test strings were added to make sure strings with capitalized
prefixes aren't treated differently (actually happened with my original
patch, Jelle had to point it out to me).
This commit adds a short section discussing the non-processing of docstrings
besides spacing improvements, mentions comment moving and links to the
AST equivalence discussion. I also added a simple spacing test for good
measure.
Commit history before merge:
* Mention comment non-processing in documentation, add spacing test
* Mention special cases for comment spacing
* Add all special cases, improve wording
Not sure the fix is right. Here is what I found: issue is connected
with line
first.prefix = prefix[comment.consumed :]
in `comments.py`. `first.prefix` is a prefix of the line, that ends
with `# fmt: skip`, but `comment.consumed` is the length of the
`" # fmt: skip"` string. If prefix length is greater than 14,
`first.prefix` will grow every time we apply formatting.
Fixes#2254
See if we pass all our repos with experimental string processing enabled.
Django probably needed:
- Ignores >= 3.8 only
We could support PEP440 version specifiers, but that would introduce the packaging module as a dependency that I'd like to avoid ... Or I could implement a poor persons version or vendor
Commit history before merge:
* [primer] Enable everything
* Add exclude extend to django CLI args for primer
* Change default timeout to from 5 to 10 mins for a primer project
* Skip string normalization for Django
* Limit Django to >= 3.8 due to := operator
The random asyncio bug is just too frequent and annoying to be
worth the speed improvements. Our test suite is already quite fast.
Random test failures hurt for 3 reasons, 1) they are discouraging for
new contributors who won't understand it's out of their control, 2)
it's annoying and time consuming to rerun the workflow, and 3) it
makes single job failures feel less important (even they should be
treated as important!).
Closes#1246: This PR adds a new option (and automatically a toml entry, hooray for existing configuration management 🎉) to require a specific version of Black to be running.
For example: `black --required-version 20.8b -c "format = 'this'"`
Execution fails straight away if it doesn't match `__version__`.
Commit history before merge:
* Add black_version to github action
* Merge upstream/main into this branch
* Add version support for the Black action pt.2
Since we're moving to a composite based action, quite a few changes
were made. 1) Support was added for all OSes (Windows was painful).
2) Isolation from the rest of the workflow had to be done manually
with a virtual environment.
Other noteworthy changes:
- Rewrote basically all of the logic and put it in a Python script
for easy testing (not doing it here tho cause I'm lazy and I can't
think of a reasonable way of testing it).
- Renamed `black_version` to `version` to better fit the existing
input naming scheme.
- Added support for log groups, this makes our action's output a
bit more fancy (I may or may have not added some debug output too).
* Add more to and sorta rewrite the Action's docs
Reflect compatability and gotchas.
* Add CHANGELOG entry
* Merge main into this branch
* Remove debug; address typos; clean up action.yml
Co-authored-by: Richard Si <63936253+ichard26@users.noreply.github.com>
PR #2286 did not fix the edge-cases (e.g. when the string is just long
enough to cause a line to be 89 characters long). This PR corrects that
mistake.
