Comments (7)
I think you can do this:
- Run
blacken-docs
on all files to see its output from what would change. git restore .
- Manually fix a file and
git add
it. - Loop.
git restore
does not undo staged changes, so you can incrementally build up your manual fix commit.
I understand your concerns about the name "--dry-run". But I couldn't come up with a better name. I don't think "--fake" is a good name, for example. Any ideas?
My concern is not about the name, it’s about how these features tend towards scope creep. Whatever we would call the option future requests to pile on more “dry run” functionality might seem reasonable (show the diff, count of files changed, ...).
I find it a bit wasteful for every code formatting tool to add dry run mode, and other common features like directory recursion support, ignore file support, etc., when there are ways to achieve the same by combining tools (the Unix philosophy).
from blacken-docs.
Is this really needed? You can test by undoing file changes with git restore
afterwards. I am currently testing #196 with:
pre-commit run blacken-docs --all ; git restore .
I'm concerned because “dry run” can mean a lot of things. Future users might expect it to output the changed file, or the diff. This feels a little like feature bloat when all the “undo changes”/diff/etc. functionality can be achieve with Git.
from blacken-docs.
If I run git restore .
I would lose all the changes. So for django/django#16261 I plan to do this "cycle" progressively:
- Run
blacken-docs
command for all docs files to get what needs to change forblacken-docs
to run - Apply manual changes for a specific file
- Re-run
Repeat until blacken-docs
can run without errors. Once that is reached, commit the changes done manually (first commit).
After the manual changes are committed, run blacken-docs
and commit the changes done by the command (second commit).
Full context: django/django#16261 (comment)
That would make review easier for that PR. And reviewers would be able to tell whether it's a manual change or a change by blacken-docs.
I understand your concerns about the name "--dry-run". But I couldn't come up with a better name. I don't think "--fake" is a good name, for example. Any ideas?
from blacken-docs.
Thanks @adamchainz ! I'll try using the flow you suggested (in the coming days).
I agree about scope creep and that "less is more".
So I'll close this issue. And ping you again in case the flow you suggested does not work.
from blacken-docs.
@adamchainz I tried the flow.
In step 3:
Manually fix a file and git add it
The only to verify a file is fixed is by running blacken-docs
, which does change the file.
This mixes my manual changes to "fix" the file with the changes by the command itself.
I need to have the command verify the file is fixed without the command further changing the file.
Is there a way to do this?
That's why I had opened #198
from blacken-docs.
I think this workflow would work? You can always add more commits with Git...
- Write an attempted fix for a file and
git add
it. - Run
blacken-docs
to see if it worked. git restore .
- If the file is fixed,
git commit
(maybe with--amend
to add to a previous commit of multiple fixes). - Loop.
from blacken-docs.
Yeah it works @adamchainz thanks. It's just that it's more work. But this should be a "one time" effort with the docs that "do not pass" yet. So it's not worth bloating blacken-docs with another argument. Thanks again!
from blacken-docs.
Related Issues (20)
- Add possibilities to skip blocks and lines? HOT 3
- RST: Detect `::` signifying default language code-block. HOT 12
- reStructuredText literal blocks within other directives
- Option to extend code block types HOT 7
- Blacken-docs does not work with tabbed indentation HOT 2
- Blacken-docs removes lines at beginning and end of codeblocks, thereby destroying the rst HOT 3
- Different exit codes for syntax errors and linting changes HOT 1
- Support formatting python code cells in Quarto document (`.qmd` extensions) HOT 1
- Fix incorrect README.md instruction HOT 2
- multi-line strings lead to incorrect syntax HOT 1
- Add support for notebook style code HOT 5
- Accept directories as input HOT 1
- Add support for a `--check` argument HOT 1
- Support Markdown fence syntax HOT 2
- Line-length issue conflicting with flake8 HOT 3
- More general `.pre-commit-hooks.yaml` for Jupyter Notebooks HOT 1
- Not failing as `pre-commit` hook due to parsing issues HOT 1
- Formatting isn't applied across the whole file HOT 3
- Parsing error with rst files with testsetup directive HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from blacken-docs.