Closed jaraco closed 10 years ago
Ok, wow. Now it's python 3.4 and windows ;)
I currently test this piece of software on travis against python 3.2 and 3.3, but on that's on linux. If you're able to execute the tests in that environment (should be pretty standard py.test + tox), i'd be very interested in any logs.
Also, message is configurable. If you like to use it productively in that environment, you could just set a message that reads "->" instead of "→".
If you manage do send a pull request that doesn't break py2/3 on linux, i'd be happy to merge that.
Indeed the custom message is a simple workaround. Perhaps we'll use that for now. As time permits, I'll work on a patch. Don't feel obliged to work on this - I more wanted to report it so the issue was captured.
Few more thoughts on this:
In the tests at https://github.com/peritus/bumpversion/blob/master/tests.py#L16 I do
environ['HGENCODING'] = 'UTF-8'
but stayed away from including that outside of the tests for some reason I don't recall anymore.
On the other hand, I could write the message to an UTF-8 encoded file then tell git/mercurial to read the message from there. That should be the safest on all platforms.
Given that Mercurial is trapped on Python 2 and Python 2 is unlikely to support proper Unicode command-line arguments, perhaps writing the message to a file would in fact be a suitable workaround. Great idea.
Very nice. Thank you.
Somehow this breaks travis but not my vagrant environment. Need to investigate.
Looks like an issue with the git config and no initialized username. Perhaps the environment changed and this commit isn't relevant.
Travis is green again: https://github.com/peritus/bumpversion/commit/aa898895b735f80319cc3d758a5d2f8157512766
When trying to invoke bumpversion using Windows on Python 3, it fails with this traceback:
This issue is due in part to the encoding of messages as bytes even though subprocess expects them to be strings.
Simply removing the encoding works around the TypeError and the program runs to completion, but the commit message has a "?" character in place of the "→". On further investigation, it appears the honoring of that character may be a bug with mercurial and not bumpversion or subprocess.
I'm able to run this simple script under Python 3 and it outputs the message properly:
Furthermore, I've confirmed that if I pass the msg to another Python 3 subprocess, the character in sys.argv is in fact unicode. If I pass the msg to a Python 2 subprocess, the character is lost and replaced by a '?'.
Overall, I believe the proper thing to do is remove the encoding of the string before passing to subprocess.
However, I suspect that will only work on Python 3 due to Python 1759845, so perhaps bumpversion should only do the encoding on Python 2.