style: tighten ruff lints #1557
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1557 +/- ##
==========================================
+ Coverage 97.30% 97.36% +0.06%
==========================================
Files 48 48
Lines 4594 4590 -4
==========================================
- Hits 4470 4469 -1
+ Misses 124 121 -3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
| { | ||
| (src / "copier.yml"): ( | ||
| """\ | ||
| build_file_tree({ |
There was a problem hiding this comment.
Is this a manual change too? I would find it surprising if Black/Ruff concatenated again ({ together instead of adding newlines and indentation levels.
There was a problem hiding this comment.
both black and ruff do this in --preview mode. likely to move into non-preview eventually but black doesn't move fast
There was a problem hiding this comment.
Just to be clear: did you manually run Ruff with preview mode enabled? If yes: is the preview mode enabled in our CI (pre-commit / poe lint / GitHub workflows / etc.)?
If it is not enabled, then I think we should revert all these style changes (like the ones in tests; the line splits and other fixes are good), and let Ruff format the code again later when such formatting is out of preview mode.
Otherwise, we could consider enabling preview mode, but I'll leave that decision to other @copier-org/maintainers.
Also, maybe I'm just too nit-picky! I'm just surprised by this new style because Black got us used to newlines, always. And I worry that not being in sync could trigger back and forth re-styling.
There was a problem hiding this comment.
Locally, I reverted the changes in tests, ran poe lint again, and it didn't style the code as what we see in this PR.
There was a problem hiding this comment.
What happens if you
- Clone this PR
- Run 'poe lint' without reverting any other changes
- Commit and push back to this PR
?
There was a problem hiding this comment.
It does nothing, and succeeds :) So one or the other style is actually not enforced, in which case I think it's preferable to keep the current style. Just my opinion!
There was a problem hiding this comment.
Can do. Will need to find some time to manually revert- hopefully tonight
There was a problem hiding this comment.
FWIW I prefer to disable preview mode of formatters. Having in mind that it's just cosmetic most times, I prefer to stick to stable releases and checks.
note that this applies ruff 'preview' formatting as a one off. This is compatible with the default ruff formatting