feat(customize.py/test_cz_customize.py): inherit from ConventionalCom…

[AtticusZeller]

enable cz_customize default behavior follow ConventionalCommitsCz without trivial settings

Description

try to Enable cover cz_conventional_commits via [tool.commitizen.customize] #1270

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

[tool.commitizen]
name = "cz_customize"
tag_format = "$version"
version_scheme = "semver"
version_provider = "pep621"
update_changelog_on_bump = true
major_version_zero = true
changelog_incremental = false

[tool.commitizen.customize]
commit_parser = "^((?P<change_type>feat|fix|refactor|perf|docs|style|refactor|ci|BREAKING CHANGE)(?:\\((?P<scope>[^()\r\n]*)\\)|\\()?(?P<breaking>!)?|\\w+!):\\s(?P<message>.*)?"
changelog_pattern = "^((BREAKING[\\-\\ ]CHANGE|\\w+)(\\(.+\\))?!?):"
change_type_map = {"feat"="Feat","fix"="Fix","refactor"= "Refactor","perf"="Perf","docs"="Docs","style"="Style","ci"="CI"}

now [tool.commitizen.customize] will cover the ConventionalCommitsCz settings

Steps to Test This Pull Request

1. add example [tool.commitizen.customize] into your pyproject.toml
2. cz commit -a,select docs,cz ch --dry-run,docs item will appear in your CHANGELOG.md

here is my test-repo

[codecov]

Codecov Report

Attention: Patch coverage is 97.72727% with 3 lines in your changes missing coverage. Please review.

Please upload report for BASE (v4@737c24c). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
commitizen/commands/commit.py	90.90%	2 Missing ⚠️
commitizen/cz/customize/customize.py	96.66%	1 Missing ⚠️

Additional details and impacted files

@@          Coverage Diff          @@
##             v4    #1274   +/-   ##
=====================================
  Coverage      ?   97.62%           
=====================================
  Files         ?       55           
  Lines         ?     2612           
  Branches      ?        0           
=====================================
  Hits          ?     2550           
  Misses        ?       62           
  Partials      ?        0           

Flag	Coverage Δ
unittests	97.62% <97.72%> (?)

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.

[AtticusZeller]

@woile

[woile]

@Lee-W what are you thoughts on this? I'm not a big user of customize. Would this change break things?

[AtticusZeller]

it's ridiculous that not allowed custom via toml.
it against Python style 😓😓😓

[woile]

I don't follow. Why is it not allowed? Can't you wait for a maintainer more familiar with customize?

[Lee-W]

Hi there, I'm a bit overwhelmed these days. Will take a look

[Lee-W]

Took a quick look. This is a great one! But this is a breaking change, so we'll include it in v4. Another thought I always have is that we should probably just deprecate cz_customize and make this behavior applicable to all the cz whenever possible.

[AtticusZeller]

Took a quick look. This is a great one! But this is a breaking change, so we'll include it in v4. Another thought I always have is that we should probably just deprecate cz_customize and make this behavior applicable to all the cz whenever possible.

thank you for review, if you plan to involve this feature, @me anytime 👋

[Lee-W]

Took a quick look. This is a great one! But this is a breaking change, so we'll include it in v4. Another thought I always have is that we should probably just deprecate cz_customize and make this behavior applicable to all the cz whenever possible.

thank you for review, if you plan to involve this feature, @me anytime 👋

We could just merge it into v4 after reviewing. But would like to know whether you're interested in designing how to make everything in a cz_ customizable through toml/json and etc. 🙂 If so, we probably could open an issue for that.
Another thing we can do is make this v4 and the ultimate customizing thing to v5.
But yep again, I only have limited bandwidth these days 🥲 (so many PR and issue waiting for me 😭) Will try my best to help!

[AtticusZeller]

But would like to know whether you're interested in designing how to make everything in a cz_ customizable through toml/json and etc.

1. of course, we love upgrading something and help each other , but be free In happy new year

2. and I believe that the following changes, reactoring custom from toml,json must be careful

because there is much functions that each one can be treated as individual Project

we should be careful on these parts interactions

inspite of the cz custom function, it's not the one would be complex. bump my version git-cliff etc. are good reference.

thanks.

[AdrianDC]

If the goal is to customize everything through .cz.yaml, modularity would in deed be helpful,
because all elements have to be reimplemented or worked around for the time being.

Completed with the other PRs, this is the configurations I implemented and use over 30-40 projects since August :
https://gitlab.com/RadianDevCore/tools/pre-commit-crocodile/-/blob/develop/.cz.yaml

As I said earlier to Lee, I'd need to take some time (after MRs) to revert it to basic Conventional Commits,
as you'll see I documented in a comments section the variations we apply (mandatory scope, security type, ! breaking changes, wip, ...)

[Lee-W]

But would like to know whether you're interested in designing how to make everything in a cz_ customizable through toml/json and etc.

1. of course, we love upgrading something and help each other , but be free In happy new year

2. and I believe that the following changes, reactoring custom from toml,json must be careful

because there is much functions that each one can be treated as individual Project

we should be careful on these parts interactions

inspite of the cz custom function, it's not the one would be complex. bump my version git-cliff etc. are good reference.

thanks.

Yep, it's indeed something we need to be cautious and would need some time to design it throughfully.

[Lee-W]

If the goal is to customize everything through .cz.yaml, modularity would in deed be helpful, because all elements have to be reimplemented or worked around for the time being.

The original goal of cz_customize. Yes.

As I said earlier to Lee, I'd need to take some time (after MRs) to revert it to basic Conventional Commits, as you'll see I documented in a comments section the variations we apply (mandatory scope, security type, ! breaking changes, wip, ...)

Yep, so what I'm thinking of is deprecating cz_customize and make every cz_ rule customizeable through toml yaml json whenever possible.

[AtticusZeller]

and by the way, I'm not sure if you'd be interested in trying to refactor using Typer, a modern Python CLI framework. It can greatly simplify existing code and easily implement type validation and common CLI components. The author is the same person who created the FastAPI framework. Here's the repo

[Lee-W]

and by the way, I'm not sure if you'd be interested in trying to refactor using Typer, a modern Python CLI framework. It can greatly simplify existing code and easily implement type validation and common CLI components. The author is the same person who created the FastAPI framework. Here's the repo

Yep, I'm aware of this lib. I guess I'm "ok" with this change if anyone wants to change it. But would like to know if @woile think it's a good idea. 🤔