Upgrade ruff

[Lee-W]

Description

• relax ruff and black constraint
• upgrade dev depedencies
• use ruff format

closes: #915

Checklist

• Add test cases to all the changes you introduce
• Run ./scripts/format and ./scripts/test locally to ensure this change passes linter check and test
• Test the changes on the local machine manually
• Update the documentation for the changes

Expected behavior

Steps to Test This Pull Request

Additional context

[codecov]

Codecov Report

Attention: 11 lines in your changes are missing coverage. Please review.

Comparison is base (120d514) 97.33% compared to head (b748d9f) 97.39%.
Report is 124 commits behind head on master.

Files	Patch %	Lines
commitizen/cli.py	82.14%	5 Missing ⚠️
commitizen/providers/scm_provider.py	91.17%	3 Missing ⚠️
commitizen/git.py	80.00%	2 Missing ⚠️
commitizen/changelog_formats/__init__.py	97.77%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #922 +/- ##
==========================================
+ Coverage 97.33% 97.39% +0.05% 
==========================================
Files 42 55 +13 Lines 2104 2341 +237 ==========================================
+ Hits 2048 2280 +232 - Misses 56 61 +5 

Flag	Coverage Δ
unittests	97.39% <97.93%> (+0.05%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[noirbizarre]

Good to me ! Beware of black versioning, using an open bounds can leads to formatting and CI breakage the day a version with updated rules is published.

[noirbizarre]

You should keep pre-commit version in sync: https://github.com/commitizen-tools/commitizen/blob/master/.pre-commit-config.yaml#L36
Maybe rely on ~= notation to avoid silent black update (or the opposite, not updated because already present in earlier version) with formatting changes in both: black~=23.11 in pre-commit and black = "~=22.10" in pyproject

[Lee-W]

good point! let me update it to black~=23.11 on both sides

[noirbizarre]

Note: I have been deploying this on my repositories lately: https://github.com/GabDug/sync-pre-commit-lock
It's a game changer: it update pre-commit hooks and keep them in sync when locking using poetry (I use it with pdm but same behavior)

[Lee-W]

Note: I have been deploying this on my repositories lately: https://github.com/GabDug/sync-pre-commit-lock It's a game changer: it update pre-commit hooks and keep them in sync when locking using poetry (I use it with pdm but same behavior)

This indeed looks cool! How do you feel about pdm? I was thinking of trying it in my personal project as well

[noirbizarre]

I am a pdm contributor and maintainer. I use it on all my personal projects (or at least I am migrating them) and I am currently migrating my clients to pdm too.
So far it's just so good !!

Note that I am currently working with a copier+ pdm + commitizen + pre-commit` stack, it's just perfect 👌🏼

[Lee-W]

I am a pdm contributor and maintainer. I use it on all my personal projects (or at least I am migrating them) and I am currently migrating my clients to pdm too. So far it's just so good !!

Note that I am currently working with a copier+ pdm + commitizen + pre-commit` stack, it's just perfect 👌🏼

Sounds cool! Will try it in my next project and see how it works 👀