Prepare for PyPI

[cthoyt]

This pull request closes #35 and makes it possible to deploy Saber to PyPI. It introduces the tox build system to run a couple of extra tests on Travis that check the integrity of the MANIFEST.in (see testenv:manifest in tox.ini) and the completeness of package metadata (see testenv:pyroma in tox.ini).

I was able to solve the problem with the external dependencies using a comment I found on StackOverflow referring to the newer system for specifying dependencies (see commit f79a3a3). After, I removed the requirements.txt since this is completely redundant of the setup.py and these are only supposed to be used for one-off projects, and not installable packages.

I'm not really sure if this broke the way code coverage was being uploaded to coveralls. I don't have any experience with that system because I've only used codecov before.

Please ask me lots of questions to explain any of the changes! If the coveralls thing doesn't work out we can try and figure that out together, too. I'm very excited to try using this myself now that I'm a bit more familiar with the codebase, and of course, that I will soon be able to use it in a reproducible way :)

Actually making the deployment

If you accept this PR and you're feeling ready to deploy to PyPI, you can use the following command, which makes use of the tox build system (see the tox.ini configuration file I added at the top level)

$ python3 -m pip install tox
$ tox -e release

Keep in mind that you can't upload the same version to PyPI ever again, so you have to bump up the version every time. It's also tricky to keep track of releases, so I'd suggest making use of the GitHub releases functionality as well so people know exactly what code in the repo made it to PyPI. Last, I'd suggest post-pending -dev to the version number between releases to help alleviate confusion

[CLAassistant]

All committers have signed the CLA.

[coveralls]

Pull Request Test Coverage Report for Build 266

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at ?%

---

Totals
Change from base Build 265:	0.0%
Covered Lines:
Relevant Lines:	0

---

💛 - Coveralls

[JohnGiorgi]

TL; DR Okay this is wicked, thanks a lot for setting this up. I am going to pull down this branch and try to use codacy for code coverage, and ditch coveralls. We already use codacy so this would mean one less tool. When that is done, I will go ahead and merge! As for submitting to PyPI, I will try my luck emailing the owner of the current saber project to see if they are willing to remove it so we can grab the name (see #35). Other than that, I may have to get you to walk me through what the workflow is like for using GitHub releases alongside PyPi... I will start reading in the meantime.

---

This pull request closes #35 and makes it possible to deploy Saber to PyPI. It introduces the tox build system to run a couple of extra tests on Travis that check the integrity of the MANIFEST.in (see testenv:manifest in tox.ini) and the completeness of package metadata (see testenv:pyroma in tox.ini).

I don't know much about tox but I will make a note to do some googling and bring myself up to speed! I think I understand the basics though.

I was able to solve the problem with the external dependencies using a comment I found on StackOverflow referring to the newer system for specifying dependencies (see commit f79a3a3). After, I removed the requirements.txt since this is completely redundant of the setup.py and these are only supposed to be used for one-off projects, and not installable packages.

Ah, I am glad you were able to solve this. I had basically given up.

I'm not really sure if this broke the way code coverage was being uploaded to coveralls. I don't have any experience with that system because I've only used codecov before.

I am going to pull down this branch and see if I can setup code coverage with codacy, which is another tool this project uses anyways. That would negate the need to use coveralls at all.

I'm very excited to try using this myself now that I'm a bit more familiar with the codebase, and of course, that I will soon be able to use it in a reproducible way :)

Thats great, excited someone else will be using the tool! I feel like I should excuse the codebase... I am not a software developer so there are bound to be design decisions and such that don't follow best practices. The API is also a little in flux (but the basic idea is to expose a few high-level methods to the user, e.g. load, save, train, annotate etc.). Please let me know if you have any trouble using the tool / any suggestions for improving the codebase.

Keep in mind that you can't upload the same version to PyPI ever again, so you have to bump up the version every time. It's also tricky to keep track of releases, so I'd suggest making use of the GitHub releases functionality as well so people know exactly what code in the repo made it to PyPI. Last, I'd suggest post-pending -dev to the version number between releases to help alleviate confusion

Okay I have never used GitHub releases so that is some more homework for me. Might have to touch base with you about what the workflow for GitHub releases + PyPi would look like.

[JohnGiorgi]

Ok, merging for now so we can snag saber on PyPI. Will fix code coverage stuff in another pull request.