peritus / bumpversion

Version-bump your software with a single command

Home Page:https://pypi.python.org/pypi/bumpversion

Repository from Github https://github.comperitus/bumpversionRepository from Github https://github.comperitus/bumpversion

tag_name option doesn't work in .bumpversion.cfg

kezabelle opened this issue · comments

Using a .bumpversion.cfg like the below, and doing bumpversion minor

[bumpversion]
commit = True
tag = True
tag_name = "{new_version}"

the tag_name argument as specified in the README.rst has no effect - it goes into parser2 as a default correctly, but somewhere along the lines it gets reset to the global default ("v{new_version}") so that when vcs.tag(args.tag_name.format(**formatargs)) is hit, the wrong string is used. I've tried this with and without quotes, without success.

Using it via the CLI, eg: `bumpversion minor --tag-name="{new_version}" works as I'd expect.

Addendum: the example in the README.rst for using it via the CLI is incorrect -- it's using the message example.

Edited to note: using 0.3.3 from PyPI.

Thanks! See, I thought I'd spare myself that test and write only one for the CLI case. Damn.

Care to submit a PR w/ a failing test and/or a fix ?

I would, but I don't have a reliable way to verify what I'm doing, and I'm not at all familiar with the inner-workings of argparse, so I can't just eyeball it:

  • The README doesn't cover what I need for testing (perhaps worth tracking as a separate ticket?):
    • I need py.test at a minimum
    • I'm assuming it's ok to ignore tox and hope that a travis build would pass, but if it's not, it'd be useful to cover what versions of python I need (hint: I don't have most of them ;))

But, having overcome that because I recognise the tests format and tox.ini, even running py.test doesn't work:

  • I get 8 failed tests, most of which appear to be OSErrors, possibly relating to the fact that the only vcs I have, or care about, is git (so anything using mercurial etc will fail, by the look of it) and I can't see a way to skip them, or only run the test I care about [this may be because I have no familiarity with py.test]
  • doing py.test --pdb is of little use, because of the aforementioned 8 failures, each of which puts me in some bit of a stacktrace I don't recognise as anything to do with __init__.py
  • putting import pdb; pdb.set_trace() into __init__.py so that I can step through and see where things are going wrong doesn't work, because py.test doesn't like it.

So ... yeah. I tried, but as I can't even get into a state where I can write a test which fails for the reason I expect, I'm afraid I can't get help further.

Alright, playing around with pdb in the source, it seems like a fix is to change this line so that instead of being default='v{new_version}') it is default=defaults.get('tag_name', 'v{new_version}')) ... which is what some of the other lines do - it make sense, and is simple enough to understand, but I'm loathe to assume it's the correct fix, because pre-existing lines like the regex parser don't do the same thing.

Yes, tox is optional (i use that mainly to test against multiple python implementations), but just py.test is fine.

I have to admit that this is largely a wrapper for argparse, yes.

That looks about right, a test for that should also be pretty straight forward. Thanks for the digging!

Note to self: Also check if message works from the config file as that looks like it is handled exactly like tag_name.

The regex parser doesn't do that because it's set as a default here.

Well, that's where my understanding of argparse falls over, because tag_name is in defaults, and gets inserted into parser3 in the same way [at least in my experimentation]. I can only assume that because it's using metavar (whatever that does!) instead of dest, it's not being picked up.

Hey. Added a failing test to demonstrate the problem (appears to be with message too). It's in the tag_name_message_from_config branch, if you want to work on top of that.

GTG,

this is part of bumpversion 0.3.4, available on PyPI as of now.