* do better with loop cleanup
* changelog
* remove redundant line
* Do this a bit better than the initial pass
* Improve windows support
Make some other things coroutines to work with improved design
* Wish we'd have done this right from the start...
* Update deps surrounding this
- see bpo-23057
- neccessary for windows users
- nice for consistent support channel info / feature availability
* dep issue
* Fix tests
* duplication plugin py version
* actually handle this
* Reconfigure some checks with codeclimate, disable pylint for now
* style
* Is my exasperation showing yet?
* handle some stupid stuff
* meh
* dep changelog
### Replacement for pipenv's environment setup
First of all, there's a new Make recipe for all devs and contributors on both Windows and Posix, `make setupenv`, which is kind of a replacement for `pipenv install --dev`. It creates a virtual environment in `.venv` using the inbuilt `venv` module, clearing out any existing virtual environment if needed first. Then it installs all dev dependencies using our new `dev-requirements.txt` file. `CONTRIBUTING.md` has been updated to reflect all of this.
### Dependency version bumping tool
Secondly, I've added a python script, `tools/bumpdeps.py` to help with bumping dependency versions. It has its own Make recipe too, `make bumpdeps`. This script won't work on Windows (yet). It reads the `tools/primary_deps.ini` file, which contains the primary requirements of Red and its extras with loose version specifiers, and outputs all pinned dependencies, in `setup.cfg` format. It's not a foolproof dependency resolver, it's quite simple, but it's bound to help out a lot. It'll try to give warnings if there might be a version conflict, but updating `setup.cfg` with its output and then doing `pip install -r dev-requirements.txt` will allow pip to issue warnings if something is conflicting.
So to add a new dependency, add it to `tools/primary_deps.ini` in the appropriate place, and either use `make bumpdeps` to completely update all dependencies, or simply add it to `setup.cfg` manually with its sub-dependencies, and all versions pinned.
### Sphinx 2.1.2 (docs changes)
The sphinx update brought along the ability to disable type annotations being rendered in function and method signatures, and I have gladly gone and done that. Type annotations should already be specified under the "Parameters" section, and the way sphinx renders them in function signatures makes them much harder to read.
Also, documented classes will now display what classes they inherit from.
Signed-off-by: Toby Harradine <tobyharradine@gmail.com>