-
Notifications
You must be signed in to change notification settings - Fork 134
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
Make 'part' optional (but not forbidden) when new_version is specified #51
Conversation
Includes a test to verify that the DeprecationWarning actually occurs. In two other tests, the warnings are suppressed to not litter the output of pytest.
It's 'file-like' if it includes a dot, slash or backslash. Unless of course there is matching part configuration (which includes the dot/slash/backslash). Without this change, test 'non_existing_file' fails because bump2version considers the supplied non-existing path to be an unnecessary [part] argument and only produces a DeprecationWarning for it. While of course we want a proper FileNotFoundError (IOError) if we supply an argument that looks like a file and can not be found on disk. Parametrize the 'non existing file' test to check all cases of dot, slash, backslash.
This avoids DeprecationWarning bubbling up to the pytest output.
61bd4de
to
47ea5da
Compare
If you supply a part when it's not required (
I think this works pretty well now. Tests are in place and I've updated the documentation. Not sure if we should use PendingDeprecationWarning instead of DeprecationWarning (see docs). |
Going to retry this in a new PR. |
This is an alternative implementation to #31 which tries to be backwards compatible to existing uses
which supply a
part
argument just because it's required by the CLI.Closes #22
I think this will only break if the part argument is actually present on disk as a file. That should be low probability since most files in the root will start with a dot or have an extension.
It's up to the maintainers to choose if #31 is preferred (it's definitely cleaner and less ambiguous) or if it's worth retaining backwards compatibility.
Future work would be to update the documentation, and to add a deprecation warning when a useless(done now)part
is supplied.