-
-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: version providers #646
Feature: version providers #646
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## v3 #646 +/- ##
=====================================
Coverage ? 97.98%
=====================================
Files ? 41
Lines ? 1834
Branches ? 0
=====================================
Hits ? 1797
Misses ? 37
Partials ? 0
Flags with carried forward coverage won't be shown. Click here to find out more. Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
99a0895
to
16c8449
Compare
9baa4b0
to
fd05fbf
Compare
Wow! Thanks, it's an interesting idea, @Lee-W what do you think? I think it could definitely work. |
Do you think we could do something like this for this #150 ? |
Yes, I think this pattern can also be applied to customize the versioning scheme. We can definitively imagine another feature splitting the versioning schemes into a |
0175ed7
to
9e6af7c
Compare
I'm really interested in this one! But kinda out of bandwidth to take a deeper look 🤦♂️ Will do so when I'm not that busy |
I came across this PR while looking for a way to ensure cz doesn't clobber dependency versions in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @noirbizarre , it's way more interesting that I previously thought! I've browsed through it and found no big issue. Wondering if there's any review order you want us to do between 645 and 646?
I've also rebased the latest master back to v3 which leads to a few conflicts 🤦♂️ |
0bfc3e1
to
973b646
Compare
There is no order or dependency between #645 and this one, but I would start with this one because it is ready to review. |
Thanks for the prompt reply! Let me start with this one 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@woile I think we're almost ready to merge this one except for a few minor changes. I'm planning on merging it this week. Let me know if you want to take a deeper look
DEFAULT = "commitizen" | ||
|
||
|
||
class VersionProvider(ABC): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think of using protocols?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this precise case, I prefer ABC
over Protocol
because:
- I expect both a constructor and methods (I could move the
config
in the method signatures, but this makes more verbose code without benefits in my opinion) - it is intended for user/community to extend this, using
ABC
force to implement methods and raise an explicit error if not, which I think is easier to understand (so more discoverable for them, less support for you)
But if you prefer Protocol
over ABC
I can switch 👍🏼
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@woile What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer Protocol
🤣 but using ABC
is fine as well. Point 2 is the key, with Protocols
people would have to use mypy
to catch the problems, I like the explicit error.
973b646
to
78c3dd7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @noirbizarre for the prompt update! I'm good with both ABC
and Protocol
. Once that discussion is resolved, I think we're good to merge this one
… versions providers
Reads version from the repository last tag matching `tag_format` Fixes commitizen-tools#641
78c3dd7
to
5672eaf
Compare
Rebased, conflicts solved. ✅ Can we merge this one please 🙏🏼 ? (because, it's starting to represent a lot of extra work for me to maintain those branches up to date for the past 2 months 😅) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @noirbizarre for your prompt update!
@woile I'm planning on merging it today. Let me know if you have any thought :)
Let's go! thanks for the awesome work! |
Description
This PR is a proposal because I know it has been stated than there won't be an official PEP621.
This PR doesn't focus on
PEP621
but on opening the version source of trust by introducing a version provider.If has been splitted in multiple commits that can be removed from the PR depending on your acceptance.
The first one is simply introducing the entrypoint
commitizen.provider
and thecommitizen
provider which is the current scheme (version taken from commitizen configuration) and backward compatible.The second one introduce some common TOML-based formats (PEP621, poetry, Cargo) as
tomlkit
is style preserving. Those implementations does not suffer from the regexp side-effect aka. changing any field matching the criteria (happen as soon as you have another version matching in the file) because they are using the format structured access instead of search and replace.The third one introduce the JSON-based providers for some formats (npm/package.json, composer), mostly to showcase the possibility (and to echo the FAQ entry for package.json/npm projects).
Given the builtin
json
is not style preserving (I assume an indentation for each one), I would totally understand their removal.The fourth one is simply a documentation update to be able to have proper snippets with title in the documentation.
The last one is exactly #647 but was required to make this PR CI green. See the previous build failing on some totally unrelated (and untouched) cases.
This PR is backward compatible (aka. it is possible not to change the version provider as well as using the
pep621
provider while handling bothCargo.toml
andpackage.json
withversion_files
), tested and documented.Note: this PR use the same extension mechanism as #632 and it is totally possible to extract all implementations to only keep the
commitizen
one given they can be provided as an external package.Edit: Added an extra commit to add an
scm
provider for #641. It handlestag_format
reverse parsing. I discovered an issue (I will submit) on thetag_format
handling: whiledevrelease
is documented as being a variable placeholder intag_format
, it is not handled as a template variable but appended to the tag (.devX
when submitted as--devrelease X
) whatever it's position is in the template, even if it is not present in the template.Checklist
./scripts/format
and./scripts/test
locally to ensure this change passes linter check and test