[Feedback Request] pycodestyle triggers on substantial amount of code. I've already added E501 to the tox.ini file. Would you all think it'd be better to include those changes in a separate PR or as part of this one?
Also, should package installs get moved from travis.yml to .ci/setup.sh?
(EDIT: Based on failing build below, code style changes may be needed (It's now using the new .yml file. Should be able to test this by commenting out the pycodestyle bit and see if the builds still fail. If they do, code needs to be linted.)

@adamsxs , since this PR w/o those changes would make master fail upon merge, I think including those changes in this PR would be best.

Also, @adamsxs, how will style errors present themselves: as warnings in the PR or as a failed unit test?

@bburns632 Currently? They are presenting themselves as a failed build (see above). It's currently executed before pytest, so don't think it counts as a unit test per se. Definitely more serious than a warning though.

In the future? Depends on how aggressively you want to enforce conventions. I think the easiest thing for maintainers, and the best for consistency across the code base, would be to keep them as errors. Based on the length of the logs from the previous builds, it's probably worth figuring out which ones are taking a stand on (errors) and which PEP8 conventions are less valuable.