-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
21 Test infrastructure #24
Conversation
Until builds are enabled for this repo... |
Codecov Report
@@ 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.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is mostly a side note than a review. I'm curious what do you think about using something like bumpversion to manage versioning instead of versioneer. I'm slightly uncomfortable with how we are including large chunks of unrelated code that mostly deals with versioning with the actual source code.
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 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Barring my own unfamiliarity with Circle-CI (and my very minor comments re. version-pins below) this looks good to me; I'd be happy to merge -- pending any further comments or objections from @sunu, of course :)
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)! :) |
#21
WIP for: