#21

Until builds are enabled for this repo...
https://ci.appveyor.com/project/KyleAltendorf/qt5reactor/history
https://travis-ci.org/altendky/qt5reactor/builds

Codecov Report

❗ No coverage uploaded for pull request base (master@11575e8). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master      #24   +/-   ##
=========================================
  Coverage          ?   30.33%           
=========================================
  Files             ?        4           
  Lines             ?      211           
  Branches          ?       25           
=========================================
  Hits              ?       64           
  Misses            ?      146           
  Partials          ?        1

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 11575e8...b9fddb9. Read the comment docs.

@sunu, I just opened #28 for the versioning discussion.

@sunu, ok, so I totally forgot I had even put Versioneer in here... so yeah, this conversation should have stayed here. Sorry. I"ll close #28 and post my response here.

I've been happy wherever I've used Versioneer. I used vcversioner, then tried setuptools_scm and was disappointed, then Versioneer and was happy again. I personally find version numbers in revision controlled source code to be wrong. Wrong both in the 'wrong approach' sense and in the 'then the vast majority of commits are incorrectly identified' sense. Unless you are really careful to bump/release/bump which just seems annoying and you still lose the per-commit identification. I can't say I 'like' the idea of having lots of versioning code in the repo... but in comparison to my other interests that is irrelevant. I believe it is possible to use Versioneer as a setup_requires though explanations I've heard of that mechanism sounds messy (bypassing pip etc).

So, sure, it seems a bit silly to have Versioneer embedded, but it provides the functionality I want and other things don't. But sure, lots of people have lots of preferences for various reasons.

Honestly, my biggest complaint isn't about Versioneer at all. Rather, PEP 440 provides no mechanism intended to describe arbitrary post-release development. So, I've been abusing the .post scheme.

@sunu, @crwood, up for a review? There's always stuff to fix and tidy but it's significantly here and I can open a ticket for the Windows coverage reporting.

To summarize, I'm proposing accepting this and creating tickets for consideration and potential resolution of the remaining items in the WIP list. AppVeyor coverage reporting and some helper for the pinned deps.

That all sounds good to me. And if @sunu has any further comments, considerations, or objections in the meantime, we can address those in other tickets as well.

Gonna go ahead and merge -- thanks again, Kyle, for all of your hard work on this (and welcome aboard as a maintainer)! :)