Feature/Attachments

[seshrs]

Added an option to send attachments with each email. This can be configured using an "attachment list" text file, which must be supplied as an option to mailmerge. The updated README explains the details of how it can be used. A functional test using attachments has also been added.

I verified that attachments were correctly identified by Gmail-based clients. I am open to suggestions on how to improve the functionality or style of code in this PR. Thanks!

[seshrs]

Ah, just saw that there's an issue for this: #20

[awdeorio]

This is great! What do you do you think about using an pseudo-header to specify attachments? See discussion here #20 (comment)

[seshrs]

Thanks! The pseudo-header is possible. My thoughts:

• Attachments would result in non-standard emails. But maybe that's the direction mailmerge should go, given Markdown Support #26.
• The attachments would have to be separated by commas or semicolons, and all on one line. Would that look cluttered? (Perhaps not, given that most people don't send too many attachments in emails.)

[awdeorio]

We're getting close!

Another question: what happens if a file has a space in it?

What if I use an absolute path? Possibly relevant: https://docs.python.org/2/library/os.path.html#os.path.abspath

What if I use a path that has a backslash, e.g., on Windows?

[seshrs]

Regarding your other comments:

• Windows-style separators: I realize I missed to use os.path.join in api.py:83. I think making this change should ensure that Windows style paths work: I can try to validate this.
• Absolute paths: I think os.path.isabs will help identify such paths. According to the docs, it also works as expected on Windows too.

Thanks for bringing these points up! Will push a new iteration soon.

[awdeorio]

I scratched a few itches, editing the README directly. Take a second look if you think it's OK.

[seshrs]

The README looks much cleaner now. Thanks for the input!

[awdeorio]

This is looking great! Once the (newly added CI) tests pass, it'll be ready to merge!

[seshrs]

The original changes failed on python2 because of a bug in the future module. Message._headers is represented as a custom list object to enable support for both python2 and python3. Unfortunately, the Message.set_boundary method converts this to a native list, which breaks some functionality in python2.

(Edit: I've created an issue in the future repository and have submitted a PR there with a fix. See PythonCharmers/python-future#429 and PythonCharmers/python-future#430)

I've implemented a work-around to avoid the set_boundary method from being called. What do you think of it? (I'm open to suggestions to making the "hack" less hacky!)

[awdeorio]

Looks great! I'm going to merge, then create an issue to remove the Message._headers work-around after your upstream PR is accepted.