Failing when input file contains mixed line endings

[connorsml]

I ran into the following issue bumping the version of a python library using bump2version 1.0.1. It wasn't an issue in the earlier version I was using but that was something like 0.5.*.

File "/stuff/python-3.7/lib/python3.7/site-packages/bumpversion/utils.py", line 144, in replace
with open(self.path, "wt", encoding="utf-8", newline=file_new_lines) as f:
TypeError: open() argument 6 must be str or None, not tuple

The error complains about argument 6, but actually only 4 arguments are passed in this case.

Argument 4 (newline) should be the newline character, and that newline character is retrieved using the following code:

    with open(self.path, "rt", encoding="utf-8") as f:
        file_content_before = f.read()
        file_new_lines = f.newlines

In the case of my setup.py there was a stray windows newline character in a file that otherwise contained Linux newline characters. This resulted in file_new_lines being a tuple, which is a unacceptable value for newline.

I converted all my newlines to the same value and it works fine, but it took a little while to debug.

Perhaps it would be appropriate to take one of them if there is multiple or choose a sensible default? If there isn't a sensible default perhaps a human readable error could be raised that makes it obvious where the issue is without the need to debug?

Thanks

[florisla]

To be honest, I knew this was an issue and would one day come up as a bug report... Sorry about that, and thanks for reporting it!

My preference would be to

• Print a warning about this, but not crash
• Select carriage-return on OS X, carriage-return+newline on Windows, and newline for anything else (Unix/Linux...)

[connorsml]

That seems like a sensible way to approach it.

[florisla]

Just found out about os.linesep -- let's use that one to support as many platforms as possible.

[connorsml]

Something like that maybe? connorsml@3ccef9e

[florisla]

Yes, that looks good. But it needs a unit test as well.