|build-badge| |license-badge| |pypi-badge| |downloads-badge| |black-badge| |changelog-badge|
.. |build-badge| image:: https://github.com/akaihola/darker/actions/workflows/python-package.yml/badge.svg :alt: master branch build status :target: https://github.com/akaihola/darker/actions/workflows/python-package.yml?query=branch%3Amaster .. |license-badge| image:: https://img.shields.io/badge/License-BSD%203--Clause-blue.svg :alt: BSD 3 Clause license :target: https://github.com/akaihola/darker/blob/master/LICENSE.rst .. |pypi-badge| image:: https://img.shields.io/pypi/v/darker :alt: Latest release on PyPI :target: https://pypi.org/project/darker/ .. |downloads-badge| image:: https://pepy.tech/badge/darker :alt: Number of downloads :target: https://pepy.tech/project/darker .. |black-badge| image:: https://img.shields.io/badge/code%20style-black-000000.svg :alt: Source code formatted using Black :target: https://github.com/psf/black .. |changelog-badge| image:: https://img.shields.io/badge/-change%20log-purple :alt: Change log :target: https://github.com/akaihola/darker/blob/master/CHANGES.rst .. |next-milestone| image:: https://img.shields.io/github/milestones/progress/akaihola/darker/25?color=red&label=release%202.1.2 :alt: Next milestone :target: https://github.com/akaihola/darker/milestone/24
This utility reformats and checks Python source code files. However, when run in a Git repository, it compares an old revision of the source tree to a newer revision (or the working tree). It then
The reformatters supported are:
See Using linters_ below for the list of supported linters.
To easily run Darker as a Pytest_ plugin, see pytest-darker_.
To integrate Darker with your IDE or with pre-commit_, see the relevant sections below in this document.
.. _Black: https://github.com/python/black .. _isort: https://github.com/timothycrosley/isort .. _flynt: https://github.com/ikamensh/flynt .. _Pytest: https://docs.pytest.org/ .. _pytest-darker: https://pypi.org/project/pytest-darker/
.. _#151: https://github.com/akaihola/darker/issues/151 .. _community support channel: https://github.com/akaihola/darker/discussions
You want to start unifying code style in your project using Black_. Maybe you also like to standardize on how to order your imports, or do static type checking or other static analysis for your code.
However, instead of formatting the whole code base in one giant commit, you'd like to only change formatting when you're touching the code for other reasons.
This can also be useful when contributing to upstream codebases that are not under your complete control.
Partial formatting is not supported by Black_ itself,
for various good reasons, and so far there hasn't been a plan to implemented it either
(134, 142, 245, 370, 511, 830).
However, in September 2021 Black developers started to hint towards adding this feature
after all (1352__). This might at least simplify Darker's algorithm substantially.
__ https://github.com/psf/black/issues/134 __ https://github.com/psf/black/issues/142 __ https://github.com/psf/black/issues/245 __ https://github.com/psf/black/issues/370 __ https://github.com/psf/black/issues/511 __ https://github.com/psf/black/issues/830 __ https://github.com/psf/black/issues/1352
But for the time being, this is where darker enters the stage.
This tool is for those who want to do partial formatting right now.
Note that this tool is meant for special situations when dealing with existing code bases. You should just use Black_ and isort_ as is when starting a project from scratch.
You may also want to still consider whether reformatting the whole code base in one
commit would make sense in your particular case. You can ignore a reformatting commit
in git blame using the blame.ignoreRevsFile_ config option or --ignore-rev on
the command line. For a deeper dive into this topic, see Avoiding ruining git blame_
in Black documentation, or the article
Why does Black insist on reformatting my entire project?_ from Łukasz Langa_
(@ambv_, the creator of Black). Here's an excerpt:
"When you make this single reformatting commit, everything that comes after is
**semantic changes** so your commit history is clean in the sense that it actually
shows what changed in terms of meaning, not style. There are tools like darker that
allow you to only reformat lines that were touched since the last commit. However,
by doing that you forever expose yourself to commits that are a mix of semantic
changes with stylistic changes, making it much harder to see what changed."
.. _blame.ignoreRevsFile: https://git-scm.com/docs/git-blame/en#Documentation/git-blame.txt---ignore-revs-fileltfilegt .. _Avoiding ruining git blame: https://black.readthedocs.io/en/stable/guides/introducing_black_to_your_project.html#avoiding-ruining-git-blame .. _Why does Black insist on reformatting my entire project?: https://lukasz.langa.pl/36380f86-6d28-4a55-962e-91c2c959db7a/ .. _Łukasz Langa: https://lukasz.langa.pl/ .. _@ambv: https://github.com/ambv
To install or upgrade, use::
pip install --upgrade darker~=2.1.1
Or, if you're using Conda_ for package management::
conda install -c conda-forge darker~=2.1.1 isort conda update -c conda-forge darker
..
**Note:** It is recommended to use the '``~=``' "`compatible release`_" version
specifier for Darker. See `Guarding against Black compatibility breakage`_ for more
information.
The darker <myfile.py> or darker <directory> command
reads the original file(s),
formats them using Black_,
combines original and formatted regions based on edits,
and writes back over the original file(s).
Alternatively, you can invoke the module directly through the python executable,
which may be preferable depending on your setup.
Use python -m darker instead of darker in that case.
By default, darker just runs Black_ to reformat the code.
You can enable additional features with command line options:
-i / --isort: Reorder imports using isort_. Note that isort_ must be
run in the same Python environment as the packages to process, as it imports
your modules to determine whether they are first or third party modules.-f / --flynt: Also convert string formatting to use f-strings using the
flynt package-L <linter> / --lint <linter>: Run a supported linter (see Using linters_)New in version 1.1.0: The -L / --lint option.
New in version 1.2.2: Package available in conda-forge_.
New in version 1.7.0: The -f / --flynt option
.. _Conda: https://conda.io/ .. _conda-forge: https://conda-forge.org/
This example walks you through a minimal practical use case for Darker.
First, create an empty Git repository:
.. code-block:: shell
$ mkdir /tmp/test $ cd /tmp/test $ git init Initialized empty Git repository in /tmp/test/.git/
In the root of that directory, create the ill-formatted Python file our_file.py:
.. code-block:: python
if True: print('hi') print() if False: print('there')
Commit that file:
.. code-block:: shell
$ git add our_file.py $ git commit -m "Initial commit" [master (root-commit) a0c7c32] Initial commit 1 file changed, 3 insertions(+) create mode 100644 our_file.py
Now modify the first line in that file:
.. code-block:: python
if True: print('CHANGED TEXT') print() if False: print('there')
You can ask Darker to show the diff for minimal reformatting which makes edited lines conform to Black rules:
.. code-block:: diff
$ darker --diff our_file.py --- our_file.py +++ our_file.py @@ -1,3 +1,4 @@ -if True: print('CHANGED TEXT') +if True:
Alternatively, Darker can output the full reformatted file (works only when a single Python file is provided on the command line):
.. code-block:: shell
$ darker --stdout our_file.py
.. code-block:: python
if True: print("CHANGED TEXT") print() if False: print('there')
If you omit the --diff and --stdout options,
Darker replaces the files listed on the command line
with partially reformatted ones as shown above:
.. code-block:: shell
$ darker our_file.py
Now the contents of our_file.py will have changed.
Note that the original print() and if False: ... lines have not been reformatted
since they had not been edited!
.. code-block:: python
if True: print("CHANGED TEXT") print() if False: print('there')
You can also ask Darker to reformat edited lines in all Python files in the repository:
.. code-block:: shell
$ darker .
Or, if you want to compare to another branch (or, in fact, any commit) instead of the last commit:
.. code-block:: shell
$ darker --revision master .
darker, Black_, isort_, flynt_ and linter behaviordarker invokes Black_ and isort_ internals directly instead of running their
binaries, so it needs to read and pass configuration options to them explicitly.
Project-specific default options for darker itself, Black_ and isort_ are read from
the project's pyproject.toml file in the repository root. isort_ does also look for
a few other places for configuration.
Mypy_, Pylint_, Flake8_ and other compatible linters are invoked as
subprocesses by darker, so normal configuration mechanisms apply for each of those
tools. Linters can also be configured on the command line, for example::
darker -L "mypy --strict" .
darker --lint "pylint --errors-only" .
flynt_ (option -f / --flynt) is also invoked as a subprocess, but passing
command line options to it is currently not supported. Configuration files need to be
used instead.
Darker does honor exclusion options in Black configuration files when recursing directories, but the exclusions are only applied to Black reformatting. Isort and linters are still run on excluded files. Also, individual files explicitly listed on the command line are still reformatted even if they match exclusion patterns.
For more details, see:
Black documentation about pyproject.toml_isort documentation about config files_public GitHub repositories which install and run Darker_flynt documentation about configuration files_The following command line arguments_ can also be used to modify the defaults:
-r REV, --revision REV
Revisions to compare. The default is HEAD..:WORKTREE: which compares the
latest commit to the working tree. Tags, branch names, commit hashes, and other
expressions like HEAD~5 work here. Also a range like main...HEAD or
main... can be used to compare the best common ancestor. With the magic value
:PRE-COMMIT:, Darker works in pre-commit compatible mode. Darker expects the
revision range from the PRE_COMMIT_FROM_REF and PRE_COMMIT_TO_REF
environment variables. If those are not found, Darker works against HEAD.
Also see --stdin-filename= for the :STDIN: special value.
--stdin-filename PATH
The path to the file when passing it through stdin. Useful so Darker can find the
previous version from Git. Only valid with --revision=<rev1>..:STDIN:
(HEAD..:STDIN: being the default if --stdin-filename is enabled).
-c PATH, --config PATH
Make darker, black and isort read configuration from PATH. Note
that other tools like flynt, mypy, pylint or flake8 won't use
this configuration file.
-v, --verbose
Show steps taken and summarize modifications
-q, --quiet
Reduce amount of output
--color
Enable syntax highlighting even for non-terminal output. Overrides the
environment variable PY_COLORS=0
--no-color
Disable syntax highlighting even for terminal output. Overrides the environment
variable PY_COLORS=1
-W WORKERS, --workers WORKERS
How many parallel workers to allow, or 0 for one per core [default: 1]
--diff
Don't write the files back, just output a diff for each file on stdout. Highlight
syntax if on a terminal and the pygments package is available, or if enabled
by configuration.
-d, --stdout
Force complete reformatted output to stdout, instead of in-place. Only valid if
there's just one file to reformat. Highlight syntax if on a terminal and the
pygments package is available, or if enabled by configuration.
--check
Don't write the files back, just return the status. Return code 0 means nothing
would change. Return code 1 means some files would be reformatted.
-f, --flynt
Also convert string formatting to use f-strings using the flynt package
-i, --isort
Also sort imports using the isort package
-L CMD, --lint CMD
Run a linter on changed files. CMD can be a name or path of the linter
binary, or a full quoted command line with the command and options. Linters read
their configuration as normally, and aren't affected by -c / --config.
Linter output is syntax highlighted when the pygments package is available if
run on a terminal and or enabled by explicitly (see --color).
-S, --skip-string-normalization
Don't normalize string quotes or prefixes
--no-skip-string-normalization
Normalize string quotes or prefixes. This can be used to override skip-string- normalization = true from a Black configuration file.
--skip-magic-trailing-comma
Skip adding trailing commas to expressions that are split by comma where each
element is on its own line. This includes function signatures. This can be used
to override skip-magic-trailing-comma = true from a Black configuration file.
-l LENGTH, --line-length LENGTH
How many characters per line to allow [default: 88]
-t VERSION, --target-version VERSION
[py33|py34|py35|py36|py37|py38|py39|py310|py311|py312] Python versions
that should be supported by Black's output. [default: per-file auto-detection]
To change default values for these options for a given project,
add a [tool.darker] section to pyproject.toml in the project's root directory,
or to a different TOML file specified using the -c / --config option.
You should configure invoked tools like Black_, isort_ and flynt_ using their own configuration files.
As an exception, the line-length and target-version options in [tool.darker]
can be used to override corresponding options for individual tools.
Note that Black_ honors only the options listed in the below example
when called by darker, because darker reads the Black configuration
and passes it on when invoking Black_ directly through its Python API.
An example pyproject.toml configuration file:
.. code-block:: toml
[tool.darker] src = [ "src/mypackage", ] revision = "master" diff = true check = true isort = true flynt = true lint = [ "pylint", ] line-length = 80 # Passed to isort and Black, override their config target-version = ["py312"] # Passed to Black, overriding its config log_level = "INFO"
[tool.black] line-length = 88 # Overridden by [tool.darker] above skip-magic-trailing-comma = false skip-string-normalization = false target-version = ["py38", "py39", "py310", "py311", "py312"] # Overridden above exclude = "test_.py" extend_exclude = "/generated/" force_exclude = "..pyi"
[tool.isort] profile = "black" known_third_party = ["pytest"] line_length = 88 # Overridden by [tool.darker] above
Be careful to not use options which generate output which is unexpected for
other tools. For example, VSCode only expects the reformat diff, so
lint = [ ... ] can't be used with it.
New in version 1.0.0:
-c, -S and -l command line options.-c and -l, too.New in version 1.1.0: The command line options
-r / --revision--diff--check--no-skip-string-normalization-L / --lintNew in version 1.2.0: Support for
-r / --revision.[tool.darker] section in pyproject.toml.New in version 1.2.2: Support for -r :PRE-COMMIT: / --revision=:PRE_COMMIT:
New in version 1.3.0: The --skip-magic-trailing-comma and -d / --stdout
command line options
New in version 1.5.0: The -W / --workers, --color and --no-color
command line options
New in version 1.7.0: The -t / --target-version command line option
New in version 1.7.0: The -f / --flynt command line option
New in version 2.1.1: In [tool.darker], deprecate the the Black options
skip_string_normalization and skip_magic_trailing_comma
.. _Black documentation about pyproject.toml: https://black.readthedocs.io/en/stable/usage_and_configuration/the_basics.html#configuration-via-a-file .. _isort documentation about config files: https://timothycrosley.github.io/isort/docs/configuration/config_files/ .. _public GitHub repositories which install and run Darker: https://github.com/search?q=%2Fpip+install+.*darker%2F+path%3A%2F%5E.github%5C%2Fworkflows%5C%2F.*%2F&type=code .. _flynt documentation about configuration files: https://github.com/ikamensh/flynt#configuration-files .. _command line arguments: https://black.readthedocs.io/en/stable/usage_and_configuration/the_basics.html#command-line-options
Many editors have plugins or recipes for integrating Black_.
You may be able to adapt them to be used with darker.
See editor integration__ in the Black_ documentation.
__ https://github.com/psf/black/#editor-integration
Install darker::
$ pip install darker
Locate your darker installation folder.
On macOS / Linux / BSD::
$ which darker /usr/local/bin/darker # possible location
On Windows::
$ where darker %LocalAppData%\Programs\Python\Python36-32\Scripts\darker.exe # possible location
Open External tools in PyCharm/IntelliJ IDEA
PyCharm -> Preferences -> Tools -> External ToolsFile -> Settings -> Tools -> External ToolsClick the + icon to add a new external tool with the following values:
"$FilePath$"If you need any extra command line arguments
like the ones which change Black behavior,
you can add them to the Arguments field, e.g.::
--config /home/myself/black.cfg "$FilePath$"
You can now format the currently opened file by selecting Tools -> External Tools -> Darker
or right clicking on a file and selecting External Tools -> Darker
Optionally, set up a keyboard shortcut at
Preferences or Settings -> Keymap -> External Tools -> External Tools - Darker
Optionally, run darker on every file save:
Make sure you have the File Watcher__ plugin installed.
Go to Preferences or Settings -> Tools -> File Watchers and click + to add
a new watcher:
$FilePath$$FilePath$$ProjectFileDir$Uncheck "Auto-save edited files to trigger the watcher"
__ https://plugins.jetbrains.com/plugin/7177-file-watchers
Install darker::
$ pip install darker
Locate your darker installation folder.
On macOS / Linux / BSD::
$ which darker /usr/local/bin/darker # possible location
On Windows::
$ where darker %LocalAppData%\Programs\Python\Python36-32\Scripts\darker.exe # possible location
Make sure you have the VSCode black-formatter extension__ installed.
__ https://github.com/microsoft/vscode-black-formatter
Add these configuration options to VSCode
(⌘ Command / Ctrl + ⇧ Shift + P
and select Open Settings (JSON))::
"python.editor.defaultFormatter": "ms-python.black-formatter", "black-formatter.path": "<install_location_from_step_2>", "black-formatter.args": ["-d"],
VSCode will always add --diff --quiet as arguments to Darker,
but you can also pass additional arguments in the black-formatter.args option
(e.g. ["-d", "--isort", "--revision=master..."]).
Be sure to not enable any linters here or in pyproject.toml
since VSCode won't be able to understand output from them.
Note that VSCode first copies the file to reformat into a temporary
<filename>.py.<hash>.tmp file, then calls Black (or Darker in this case) on that
file, and brings the changes in the modified files back into the editor.
Darker is aware of this behavior, and will correctly compare .py.<hash>.tmp files
to corresponding .py files from earlier repository revisions.
Unlike Black_ and many other formatters, darker needs access to the Git history.
Therefore it does not work properly with classical auto reformat plugins.
You can though ask vim to run darker on file save with the following in your
.vimrc:
.. code-block:: vim
set autoread autocmd BufWritePost *.py silent :!darker %
BufWritePost to run darker once the file has been saved,silent to not ask for confirmation each time,:! to run an external command,% for current file name.Vim should automatically reload the file.
You can integrate with Emacs using Steve Purcell's emacs-reformatter__ library.
Using use-package__:
.. code-block:: emacs-lisp
(use-package reformatter
:hook ((python-mode . darker-reformat-on-save-mode))
:config
(reformatter-define darker-reformat
:program "darker"
:stdin nil
:stdout nil
:args (list "-q" input-file))
This will automatically reformat the buffer on save.
You have multiple functions available to launch it manually:
__ https://github.com/purcell/emacs-reformatter __ https://github.com/jwiegley/use-package
New in version 1.2.1
To use Darker locally as a Git pre-commit hook for a Python project, do the following:
Install pre-commit_ in your environment
(see pre-commit Installation_ for details).
Create a base pre-commit configuration::
pre-commit sample-config >.pre-commit-config.yaml
Append to the created .pre-commit-config.yaml the following lines:
.. code-block:: yaml
install the Git hook scripts and update to the newest version::
pre-commit install
pre-commit autoupdate
When auto-updating, care is being taken to protect you from possible incompatibilities
introduced by Black updates. See Guarding against Black compatibility breakage_ for
more information.
If you'd prefer to not update but keep a stable pre-commit setup, you can pin Black and other reformatter/linter tools you use to known compatible versions, for example:
.. code-block:: yaml
.. _pre-commit: https://pre-commit.com/ .. _pre-commit Installation: https://pre-commit.com/#installation
You can provide arguments, such as enabling isort, by specifying args.
Note the inclusion of the isort Python package under additional_dependencies:
.. code-block:: yaml
You can use Darker within a GitHub Actions workflow without setting your own Python environment. Great for enforcing that modifications and additions to your code match the Black_ code style.
This action is known to support all GitHub-hosted runner OSes. In addition, only
published versions of Darker are supported (i.e. whatever is available on PyPI).
You can search workflows in public GitHub repositories_ to see how Darker is being
used.
.. _search workflows in public GitHub repositories: https://github.com/search?q=%22uses%3A+akaihola%2Fdarker%22+path%3A%2F%5E.github%5C%2Fworkflows%5C%2F.*%2F&type=code
Create a file named .github/workflows/darker.yml inside your repository with:
.. code-block:: yaml
name: Lint
on: [push, pull_request]
jobs: lint: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - uses: actions/setup-python@v5 - uses: akaihola/darker@2.1.1 with: options: "--check --diff --isort --color" src: "./src" version: "~=2.1.1" lint: "flake8,pylint==2.13.1"
There needs to be a working Python environment, set up using actions/setup-python
in the above example. Darker will be installed in an isolated virtualenv to prevent
conflicts with other workflows.
"uses:" specifies which Darker release to get the GitHub Action definition from.
We recommend to pin this to a specific release.
"version:" specifies which version of Darker to run in the GitHub Action.
It defaults to the same version as in "uses:",
but you can force it to use a different version as well.
Darker versions available from PyPI are supported, as well as commit SHAs or branch
names, prefixed with an @ symbol (e.g. version: "@master").
The revision: "master..." (or "main...") option instructs Darker
to compare the current branch to the branching point from main branch
when determining which source code lines have been changed.
If omitted, the Darker GitHub Action will determine the commit range automatically.
"src:" defines the root directory to run Darker for.
This is typically the source tree, but you can use "." (the default)
to also reformat Python files like "setup.py" in the root of the whole repository.
You can also configure other arguments passed to Darker via "options:".
It defaults to "--check --diff --color".
You can e.g. add "--isort" to sort imports, or "--verbose" for debug logging.
To run linters through Darker, you can provide a comma separated list of linters using
the lint: option. Only flake8, pylint and mypy are supported. Other
linters may or may not work with Darker, depending on their message output format.
Versions can be constrained using pip syntax, e.g. "flake8>=3.9.2".
New in version 1.1.0: GitHub Actions integration. Modeled after how Black_ does it, thanks to Black authors for the example!
New in version 1.4.1:
The revision: option, with smart default value if omitted.
New in version 1.5.0:
The lint: option.
.. _Using linters:
One way to use Darker is to filter linter output to only those linter messages which appeared after the modifications to source code files, as well as old messages which concern modified lines. Darker supports any linter with output in one of the following formats::
<file>:<linenum>: <description>
<file>:<linenum>:<col>: <description>
Most notably, the following linters/checkers have been verified to work with Darker:
cov_to_lint.py_ for test coverageNew in version 1.1.0: Support for Mypy_, Pylint_, Flake8_ and compatible linters.
New in version 1.2.0: Support for test coverage output using cov_to_lint.py_.
To run a linter, use the --lint / -L command line option with the linter
command or a full command line to pass to a linter. Some examples:
-L flake8: enforce the Python style guide using Flake8_-L "mypy --strict": do static type checking using Mypy_--lint="pylint --ignore='setup.py'": analyze code using Pylint_-L cov_to_lint.py: read .coverage and list non-covered modified linesNote: Full command lines aren't fully tested on Windows. See issue #456_ for a
possible bug.
Darker also groups linter output into blocks of consecutive lines
separated by blank lines.
Here's an example of cov_to_lint.py_ output::
$ darker --revision 0.1.0.. --check --lint cov_to_lint.py src
src/darker/__main__.py:94: no coverage: logger.debug("No changes in %s after isort", src)
src/darker/__main__.py:95: no coverage: break
src/darker/__main__.py:125: no coverage: except NotEquivalentError:
src/darker/__main__.py:130: no coverage: if context_lines == max_context_lines:
src/darker/__main__.py:131: no coverage: raise
src/darker/__main__.py:132: no coverage: logger.debug(
+-----------------------------------------------------------------------+ | ⚠ NOTE ⚠ | +=======================================================================+ | Don't enable linting on the command line or in the configuration when | | running Darker as a reformatter in VSCode. You will confuse VSCode | | with unexpected output from Darker, as it only expect black's output | +-----------------------------------------------------------------------+
.. _Mypy: https://pypi.org/project/mypy .. _Pylint: https://pypi.org/project/pylint .. _Flake8: https://pypi.org/project/flake8 .. _cov_to_lint.py: https://gist.github.com/akaihola/2511fe7d2f29f219cb995649afd3d8d2 .. _#456: https://github.com/akaihola/darker/issues/456
Darker automatically enables syntax highlighting for the --diff,
-d/--stdout and -L/--lint options if it's running on a terminal and the
Pygments_ package is installed.
You can force enable syntax highlighting on non-terminal output using
color = true option in the [tool.darker] section of pyproject.toml of
your Python project's root directory,PY_COLORS=1 environment variable, and--color command line option for darker.You can force disable syntax highlighting on terminal output using
color = false option in pyproject.toml,PY_COLORS=0 environment variable, and--no-color command line option.In the above lists, latter configuration methods override earlier ones, so the command line options always take highest precedence.
.. _Pygments: https://pypi.org/project/Pygments/
Darker accesses some Black internals which don't belong to its public API. Darker is thus subject to becoming incompatible with future versions of Black.
To protect users against such breakage, we test Darker daily against the Black main branch_ and strive to proactively fix any potential incompatibilities through this
process. If a commit to Black main branch introduces an incompatibility with
Darker, we will release a first patch version for Darker that prevents upgrading Black
and a second patch version that fixes the incompatibility. A hypothetical example:
main (after 35.12.0)
-> ERROR on CI test-future_ workflowBlack<=35.12.0
-> OKIf a Black release introduces an incompatibility before the second Darker patch version that fixes it, the first Darker patch version will downgrade Black to the latest compatible version:
Black<=35.12.0; downgrades to Black 35.12.0
-> OKTo be completely safe, you can pin both Darker and Black to known good versions, but this may prevent you from receiving improvements in Black.
It is recommended to use the '~=' "compatible release_" version specifier for
Darker to ensure you have the latest version before the next major release that may
cause compatibility issues.
See issue #382_ and PR #430_ for more information.
.. _compatible release: https://peps.python.org/pep-0440/#compatible-release .. _Black main branch: https://github.com/psf/black/commits/main .. _test-future: https://github.com/akaihola/darker/blob/master/.github/workflows/test-future.yml .. _#382: https://github.com/akaihola/darker/issues/382 .. _#430: https://github.com/akaihola/darker/issues/430
To apply Black reformatting and to modernize format strings on changed lines, Darker does the following:
git diff of Python files between REV1 and REV2 as specified using
the --revision=REV1..REV2 optionTo sort imports when the --isort option was specified, Darker proceeds like this:
For details on how linting support works, see Graylint_ documentation.
Black doesn't support partial formatting natively. Because of this, Darker lets Black reformat complete files. Darker then accepts or rejects chunks of contiguous lines touched by Black, depending on whether any of the lines in a chunk were edited or added between the two revisions.
Due to the nature of this algorithm, Darker is often unable to minimize the number of changes made by Black as carefully as a developer could do by hand. Also, depending on what kind of changes were made to the code, diff results may lead to Darker applying reformatting in an invalid way. Fortunately, Darker always checks that the result of reformatting converts to the same AST as the original code. If that's not the case, Darker expands the chunk until it finds a valid reformatting. As a result, a much larger block of code may be reformatted than necessary.
The most reasonable work-around to these limitations is to review the changes made by Darker before committing them to the repository and unstaging any changes that are not desired.
BSD. See LICENSE.rst.
__ https://github.com/wbolster/black-macchiato __ https://github.com/Carreau/darken __ https://github.com/Carreau
The following projects are related to Black_ or Darker in some way or another. Some of them we might want to integrate to be part of a Darker run.
#51_)__ https://github.com/asottile/blacken-docs __ https://github.com/keewis/blackdoc __ https://github.com/Carreau/velin __ https://pypi.org/project/numpydoc __ https://gitlab.com/sVerentsov/diff-cov-lint __ https://github.com/rubik/xenon __ https://github.com/asottile/pyupgrade __ https://github.com/google/yapf/blob/main/yapf/third_party/yapf_diff/yapf_diff.py .. _yapf: https://github.com/google/yapf .. _#51: https://github.com/akaihola/darker/pull/51 .. _Graylint: https://github.com/akaihola/graylint
See README.rst_ for the list of contributors.
This project follows the all-contributors_ specification. Contributions of any kind are welcome!
.. _README.rst: https://github.com/akaihola/darker/blob/master/README.rst .. _emoji key: https://allcontributors.org/docs/en/emoji-key .. _all-contributors: https://allcontributors.org
|stargazers|_
.. |stargazers| image:: https://starchart.cc/akaihola/darker.svg .. _stargazers: https://starchart.cc/akaihola/darker
FAQs
Apply Black formatting only in regions changed since last commit
We found that darker demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Snyk's use of malicious npm packages for research raises ethical concerns, highlighting risks in public deployment, data exfiltration, and unauthorized testing.
Research
Security News
Socket researchers found several malicious npm packages typosquatting Chalk and Chokidar, targeting Node.js developers with kill switches and data theft.
Security News
pnpm 10 blocks lifecycle scripts by default to improve security, addressing supply chain attack risks but sparking debate over compatibility and workflow changes.