bumpversion and setuptools have differing interpolation behavior

[SethMMorton]

First, thanks for the great tool!

The interpolation behavior of config files by bumpversion and setuptools is not the same. bumpversion uses no interpolation (e.g. configparser.RawConfigParser), but setuptools uses the default interpolation of configparser.ConfigParser, which is "basic interpolation".

In general, this should not be an issue, but because bumpversion supports setting configuration in the setup.cfg file, options that might be interpolated by the parser would not cause an issue if they appear in the .bumpversion.cfg, but suddenly break the install/build process if they are moved to the setup.cfg.

For example, I had the following in my .bumpversion.cfg to automatically insert the date in my CHANGELOG along with the version.

[bumpversion:file:docs/source/changelog.rst]
search = XX-XX-XXXX v. X.X.X
replace = {now:%m-%d-%Y} v. {new_version}

When I moved this into my setup.cfg, bumpversion still works but the following happens when I try to run anything with setup.py.

Traceback (most recent call last):
 ...
configparser.InterpolationSyntaxError: '%' must be followed by '%' or '(', found: '%m-%d-%Y} v. {new_version}'

The obvious solution of escaping the % so that they are not interpolated (e.g. {now:%%m-%%d-%%Y} causes setuptools to not fail, but then bumpversion inserts the literal string "%%m-%%d-%%Y" instead of formatting the date because the percent signs are not treated as needing escaping.

It turns out that other packages have run into this, like pytest: pytest-dev/pytest#3062. This distutils mailing thread also illustrates that the python devs are struggling with if this was a good design decision, but that's a whole other can of worms.

My proposal: When loading from setup.cfg, use configparser.ConfigParser, and when loading from .bumpversion.cfg, use configparser.RawConfigParser.

[espoelstra]

Does the str.format style of using '{named}{fields}'.format(named=one,fields=many) work instead of the % formatting?

[SethMMorton]

@espoelstra It is already using str.format. Sending a datetime object through str.format requires the old-style % formatting within the format string - see https://stackoverflow.com/a/22842734/1399279.

So, in my above example, something like the following is what is happening in the code

new_string = '{now:%m-%d-%Y} v. {new_version}'.format(now=datetime.datetime.now(), new_version=new_version_string)