Feature download files

[verybadsoldier]

Adds viewing and downloading source and artifact files.

Solves #81 and #91

[verybadsoldier]

As a nice to have, the file could have its modification timestamp set correctly, but I think it's fine (unless someone needs it).

Added that in the latest commit. Good point.

My only concern would be whether the file names should really be stored using absolute paths. I had some troubles opening them under Windows (see the double backslash in the path).

Well, I am not entirely happy with it either but I had no good alternative idea yet. One obvious option would be to store all files as a flat structure in the ZIP. Duplicated filenames would have to been handled. Probably like myfile.py and myfile.py (2).
But preserving the original directory structure of the files would generally be nice also.

[chovanecm]

1. regarding Python 3.5: I am not sure how long Sacredboard should support it. I am quite happy that there not (that many) people reporting incompatibility with Python 2.7. Maybe it's also time to abandon 3.5 compatibility. I don't have enough data to decide :(
2. regarding paths: It's fine for me with absolute paths but an alternative might be using the experiment's base_dir. But I'm not sure what happens if one of the files were stored outside that base dir. I think we are better off with absolute paths than to mess with such special cases.

[chovanecm]

I will try to work around that failing test_removing_a_run* tests. Something in the testing library must have changed.

[verybadsoldier]

I am currently struggling to get the high score on those Travis checks ;-)

[chovanecm]

I have marked the failing tests to be skipped because the problem is obviously not in Sacredboard.

[chovanecm]

What if someone writes implementation for a non-mongoDB backend? There would be no gridfs.
Do you think you could wrap the result of the get method to something more generic?
Thank you

[verybadsoldier]

I see what you mean but I think it is generic in a way by seeing it as duck typing. The returned file object should have the attributes filename, upload_date and read(). So another backend would have to return an object that also provides these attributes and it should work.

In any case the variable annotation from file: gridfs.Gridout is gone already (mainly because Python 3.6 but you are right that it would not be generic).

Ofc I can still change it if you want. For example to a dict as it is done in the metricsdao.py.

[chovanecm]

OK, I'm fine with duck typing (I didn't realise that timetuple() is a method of datetime).
But I'd like to see it documented somewhere (e.g. as a docstring in the FilesDAO class or as a unit test checking whether the returned object is really a "duck" :-) ) - just to make it clear to other developers who would eventually implement it for another back-end.

[verybadsoldier]

Yes good point. I added that information to the docstring of the abstract class.

[coveralls]

Coverage decreased (-2.9%) to 76.522% when pulling 273c4d9 on verybadsoldier:feature-download_files into b78c54c on chovanecm:develop.