Problem adjusting search pattern to control greediness

[amotl]

Dear @peritus,

first things first: Thanks for conceiving and maintaining this fine piece of software. It saves the world thousands of keystrokes a day and we use it intensively in our daily workflow.

Sometimes, bumpversion accidentally bumps versions of dependency packages in setup.py. Running into this issue is always confusing like "who broke the dependencies in setup.py again?", but we couldn't make up an appropriate example for showing it to you.

But here you are, the best canonical example we can get: bumpversion bumped itself from 0.5.3 to 0.5.4 into non-existence ;]. To see this in action, please have a look at the commit https://github.com/ip-tools/uspto-opendata-python/commit/2dd8e237.

Do you have an idea what we can do to prevent this problem of bumpversion bumping versions of package dependencies?

Thanks in advance for your efforts!

With kind regards, Andreas.

P.S.: Also the "keyring" package got bumped from 10.5.3 to 10.5.4, which obviously was not intended as well.

P.P.S.: See also the active .bumpversion.cfg file of the project.

[ionelmc]

You should use the search option to restrict replacements.

[peritus]

Hey @amotl, hope you're doing well, wherever you are these days :) Haven't maintained this much in the past years, and I'm kind of astonished that it is heavily used still.

So, @ionelmc is basically right. You can use the search = option to specify a more specific string for the search/replace option.

[amotl]

Hey guys, thanks for your quick reply!

I just updated the projects' .bumpversion.cfg honoring your suggestions and it still seems to work. Very cool, that minor issue had annoyed me regularly and i wasn't aware of the search option yet.

Thanks a bunch!

[amotl]

Dear Filip (@peritus), dear bumpversion community,

it just occurred again with https://github.com/hiveeyes/phenodata/commit/c4fc58ab: bumpversion tried to upgrade from docopt==0.6.2 to docopt==0.6.3 when just attempting to bump our own phenodata module from 0.6.2 to 0.6.3.

This happens despite having configured the respective .bumpversion.cfg appropriately - at least we believed having so.

We did some investigations why this would happen and want to share our outcome. Enjoy!

1. Configuring the "search" option like seen in the .bumpversion.cfg referenced above does not work. The first line after "search = " must not be empty, you have to do it that way:

   search = version='{current_version}'
            __version__ = '{current_version}'
            version = u'{current_version}'
            release = u'{current_version}'

   This is on us.

2. After fixing this, it still didn't work. Bummer! We took the chance to have a look under the hood of the def replace workhorse. So:

   • We didn't find appropriate code being capable of replacing multiple distinct search expressions at L243 at all. Obviously, the current code will not find any replacements when configured with the search patterns listed above as they are treated as a single opaque string and used as a full search expression.

   • Things start going haywire after checking no replacement has taken place at L249, where bumpversion is running a second replacement attempt presumably as a fallback. Here, just current_version.original is used as the search string, so bumpversion actually will perform the replacements as if nothing special has been configured at all. This essentially renders the feature useless or even slightly dangerous.

Please bear with us if we got something wrong when reading bumpversions code. Maybe we missed the place where everything is happening correctly and we just have misconfigured our instance. Otherwise, we will be happy to help getting this issue finally right.

While the world definitvely will keep on spinning anyway, we would be happy if you see any slight chance to improve the situation as we are regularly running into this. Through their subtle nature and the fact packaging usually runs after CI, anomalies like these have a reasonable chance of making it beyond QA and everyone feels sad about having published broken eggs ;].

Thanks in advance for your efforts and keep up the good work!

Cheers, Andreas.

[arcanefoam]

Hi amotl, First, as peritus commented development of this project has been dead for a while. You should open this bug/feature request in bumpversion2.

As a workaround (and perhaps good practice) I would suggest you to use a version file. Basically create a "__version.py" file in module folder. The contents will be just the version:

__version__ = "0.0.1"

The, from your other files, import the version one and pick the version from that, e.g. setup.py:

import pymof
...
setup(
    name='pymof',
    version=pymof.__version__,
   ...

and in pymof.init.py (to make version available package wide):

from .__version import __version__`

Then your bumpersion.cfg only has to modify one file (the __version.py).

This makes bumpversion less prone to messing up and also makes it easier for manual housekeeping of versions (if needed at some point).

[ionelmc]

Importing stuff in setup.py is a packaging anti-pattern. Stop doing that, it will make your package uninstallable as soon as you start doing imports and stuff in your __init__.py.

[amotl]

Thanks for your suggestions, @arcanefoam! We are actually doing this from time to time but still prefer having the version string verbatim inside setup.py, which otherwise can be problematic sometimes, as @ionelmc suggested.

However, there are always things to bump beyond the world of Python ;], that's the reason we enjoy the agnostic attitude of bumpversion very much in general.

We haven't been aware of bumpversion2 yet, so we will definitively head over there. Thanks again!

[amotl]

May i humbly ask you where we can find bumpversion2 already, @arcanefoam or @peritus? We haven't been able to find it on PyPI or GitHub.

[arcanefoam]

Misspelled the name: https://github.com/c4urself/bump2version

[amotl]

Thanks a bunch! As far as i can see, this fork also has the problem of not honoring the "search" option appropriately. We will cross-post the issue there and see what we might be able to contribute to mitigate this problem.

Do you officially endorse heading over to bump2version or would you be happy to accept an eventual pull request to your original version also, @peritus? Do you plan to reintegrate the changes happening in the fork into your mainline version or shall we consider it officially abandoned?

How ever this might turn out: Thank you so much for conceiving this fine piece of software, @peritus!