`0.12.0` regression: multiple search & replace directives ignored
Closed this issue · 2 comments
kdeldycke commented
- bump-my-version version:
0.12.0 - Python version: 3.12
- Operating System: macOS
Description
I have found a regression in 0.12.0 compared to 0.11.0.
In which a mix of regex and non-regex replacement sections over the same file are no longer applied. Only one of the two is performed while the other is silently ignored.
What I Did
Given the citation.cff file containing:
version: 4.7.2
date-released: 2023-09-19
And a pyproject.toml:
[tool.bumpversion]
current_version = "4.7.2"
allow_dirty = true
[[tool.bumpversion.files]]
filename = "./citation.cff"
search = "version: {current_version}"
replace = "version: {new_version}"
[[tool.bumpversion.files]]
filename = "./citation.cff"
regex = true
search = "date-released: \\d{{4}}-\\d{{2}}-\\d{{2}}"
replace = "date-released: {utcnow:%Y-%m-%d}"When I try to perform a search and replace operation, I get:
$ bump-my-version bump --dry-run --verbose patch
Starting BumpVersion 0.12.0
Reading config file pyproject.toml:
Parsing version '4.7.2' using regexp '(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)'
Parsed the following values: major=4, minor=7, patch=2
Attempting to increment part 'patch'
Values are now: major=4, minor=7, patch=3
New version will be '4.7.3'
Dry run active, won't touch any files.
Asserting files ./citation.cff contain the version string...
Found 're.compile('date-released: \\d{4}-\\d{2}-\\d{2}', re.MULTILINE|re.DOTALL)' in ./citation.cff at line 2: date-released: 2023-09-19
Would change file ./citation.cff:
*** before ./citation.cff
--- after ./citation.cff
***************
*** 1,2 ****
version: 4.7.2
! date-released: 2023-09-19
--- 1,2 ----
version: 4.7.2
! date-released: 2023-11-05
Would write to config file pyproject.toml:
*** before pyproject.toml
--- after pyproject.toml
***************
*** 1,5 ****
[tool.bumpversion]
! current_version = "4.7.2"
allow_dirty = true
[[tool.bumpversion.files]]
--- 1,5 ----
[tool.bumpversion]
! current_version = "4.7.3"
allow_dirty = true
[[tool.bumpversion.files]]
See how the date in citation.cff is updated as expected.
But I am also expecting the version: line in citation.cff to be updated too. Which is not the case.
Regression
Note that this behavior was working as expected in bump-my-version 0.11.0.
With a pyproject.toml written with 0.11.0 syntax (only the no_regex setting is adjusted):
[tool.bumpversion]
current_version = "4.7.2"
allow_dirty = true
[[tool.bumpversion.files]]
filename = "./citation.cff"
no_regex = true
search = "version: {current_version}"
replace = "version: {new_version}"
[[tool.bumpversion.files]]
filename = "./citation.cff"
no_regex = false
search = "date-released: \\d{{4}}-\\d{{2}}-\\d{{2}}"
replace = "date-released: {utcnow:%Y-%m-%d}"I get the behavior I am expecting:
$ bump-my-version bump --dry-run --verbose patch
Starting BumpVersion 0.11.0
Reading config file pyproject.toml:
Parsing version '4.7.2' using regexp '(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)'
Parsed the following values: major=4, minor=7, patch=2
Attempting to increment part 'patch'
Values are now: major=4, minor=7, patch=3
New version will be '4.7.3'
Dry run active, won't touch any files.
Asserting files ./citation.cff contain the version string...
Found 're.compile('version: 4\\.7\\.2', re.MULTILINE|re.DOTALL)' in ./citation.cff at line 1: version: 4.7.2
Found 're.compile('date-released: \\d{4}-\\d{2}-\\d{2}', re.MULTILINE|re.DOTALL)' in ./citation.cff at line 2: date-released: 2023-09-19
Would change file ./citation.cff:
*** before ./citation.cff
--- after ./citation.cff
***************
*** 1,2 ****
! version: 4.7.2
date-released: 2023-09-19
--- 1,2 ----
! version: 4.7.3
date-released: 2023-09-19
Would change file ./citation.cff:
*** before ./citation.cff
--- after ./citation.cff
***************
*** 1,2 ****
version: 4.7.2
! date-released: 2023-09-19
--- 1,2 ----
version: 4.7.2
! date-released: 2023-11-05
Would write to config file pyproject.toml:
*** before pyproject.toml
--- after pyproject.toml
***************
*** 1,5 ****
[tool.bumpversion]
! current_version = "4.7.2"
allow_dirty = true
[[tool.bumpversion.files]]
--- 1,5 ----
[tool.bumpversion]
! current_version = "4.7.3"
allow_dirty = true
[[tool.bumpversion.files]]
Compared to the previous behavior, you can see how both the date and version are replaced in the citation.cff file.
kdeldycke commented
Additional note
Forcing the regex setting in 0.12.0 does not have any influence:
[tool.bumpversion]
current_version = "4.7.2"
allow_dirty = true
[[tool.bumpversion.files]]
filename = "./citation.cff"
regex = true
search = "version: {current_version}"
replace = "version: {new_version}"
[[tool.bumpversion.files]]
filename = "./citation.cff"
regex = true
search = "date-released: \\d{{4}}-\\d{{2}}-\\d{{2}}"
replace = "date-released: {utcnow:%Y-%m-%d}"$ bump-my-version bump --dry-run --verbose patch
Starting BumpVersion 0.12.0
Reading config file pyproject.toml:
Parsing version '4.7.2' using regexp '(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)'
Parsed the following values: major=4, minor=7, patch=2
Attempting to increment part 'patch'
Values are now: major=4, minor=7, patch=3
New version will be '4.7.3'
Dry run active, won't touch any files.
Asserting files ./citation.cff contain the version string...
Found 're.compile('date-released: \\d{4}-\\d{2}-\\d{2}', re.MULTILINE|re.DOTALL)' in ./citation.cff at line 2: date-released: 2023-09-19
Would change file ./citation.cff:
*** before ./citation.cff
--- after ./citation.cff
***************
*** 1,2 ****
version: 4.7.2
! date-released: 2023-09-19
--- 1,2 ----
version: 4.7.2
! date-released: 2023-11-05
Would write to config file pyproject.toml:
*** before pyproject.toml
--- after pyproject.toml
***************
*** 1,5 ****
[tool.bumpversion]
! current_version = "4.7.2"
allow_dirty = true
[[tool.bumpversion.files]]
--- 1,5 ----
[tool.bumpversion]
! current_version = "4.7.3"
allow_dirty = true
[[tool.bumpversion.files]]
So this regression doesn't seems to be related to the recent change in the way the --regex/--no-regex flag is encoded.
coordt commented
This was something I noticed as well and was fixed in 0.14.0