Write commit messages to temporary files

[jaraco]

When trying to invoke bumpversion using Windows on Python 3, it fails with this traceback:

C:\Users\jaraco\yg\pan [default tip]> bumpversion.pya minor
Traceback (most recent call last):
  File "c:\python\scripts\bumpversion.pya", line 9, in <module>
    load_entry_point('bumpversion==0.3.8', 'console_scripts', 'bumpversion')()
  File "C:\Program Files\Python34\lib\site-packages\bumpversion-0.3.8-py3.4.egg\bumpversion\__init__.py", line 579, in main
  File "C:\Program Files\Python34\lib\site-packages\bumpversion-0.3.8-py3.4.egg\bumpversion\__init__.py", line 163, in commit
  File "C:\Program Files\Python34\lib\subprocess.py", line 605, in check_output
    with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
  File "C:\Program Files\Python34\lib\subprocess.py", line 848, in __init__
    restore_signals, start_new_session)
  File "C:\Program Files\Python34\lib\subprocess.py", line 1078, in _execute_child
    args = list2cmdline(args)
  File "C:\Program Files\Python34\lib\subprocess.py", line 661, in list2cmdline
    needquote = (" " in arg) or ("\t" in arg) or not arg
TypeError: Type str doesn't support the buffer API

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:

# -*- coding: utf-8 -*-

import subprocess

msg = "A \u2192 B"
msg2 = "A → B"
assert msg == msg2
subprocess.call(["Powershell", "-C", "echo '" + msg + "'"])

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.

[peritus]

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.

[peritus]

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.

[jaraco]

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.

[peritus]

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.

[jaraco]

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.

[jaraco]

Very nice. Thank you.

[peritus]

Somehow this breaks travis but not my vagrant environment. Need to investigate.

[jaraco]

Looks like an issue with the git config and no initialized username. Perhaps the environment changed and this commit isn't relevant.

[peritus]

Travis is green again: aa89889