Fix setup.py and use of requirements files and add a docker test container#826
Conversation
|
It looks like CI isn't healthy. Do you want some help with that? |
Sorry, something went wrong.
|
Thanks a bunch for uncovering this, and for the fix! It looks like one travis failure legit, as it is flake not liking some whitespace. Please have a look at the comment there - maybe we can make a fix here so #825 can then be merged, too. CC @cclauss |
Sorry, something went wrong.
a0a277d to
442c7f9
Compare
January 20, 2019 15:29
Codecov Report
@@ Coverage Diff @@
## master #826 +/- ##
==========================================
- Coverage 94.79% 94.67% -0.13%
==========================================
Files 59 59
Lines 9603 9386 -217
==========================================
- Hits 9103 8886 -217
Misses 500 500
Continue to review full report at Codecov.
|
Sorry, something went wrong.
023b17e to
c045246
Compare
January 20, 2019 15:58
|
What about the windows failures? |
Sorry, something went wrong.
But the lines just above that say that the current version of setuptools (40.6.3) was just installed. Either don't upgrade setup tools or eliminate the hardcoding of setuptools-27.2.0. |
Sorry, something went wrong.
|
What I was asking is do you want to ignore those too? I'd prefer to merge this, and then deal with the CI failures, instead of bundling them all together... these changes improve (and fix) the setup.py issues. |
Sorry, something went wrong.
|
You are asking the wrong guy... I have never been a Windows fan. ;-) I would vote to move forward as is. |
Sorry, something went wrong.
|
Do we need the last three windows builds for "miniconda" or "git running in cygwin on windows"? The latter just looks like a test environment failure as it is passing windows paths (from the windows native python 3.5-x64) into a program looking for a unix path. I have no idea what the "conda" ones are or if they provide any real value. |
Sorry, something went wrong.
|
The test suite makes a very bad assumption that you are on the master branch. When I work on a project, I fork it, then I make a branch for each of the changes I am making, and submit pull requests from the branch into the upstream master. This is best practices for github development. I cannot run the test suite if I have anything else checked out. The test suite fails. It is making some bad assumptions. When I run inside a docker container and skip past those, even with python 3.6, I'm seeing other issues like utf8 issues. |
Sorry, something went wrong.
0ede297 to
03342ce
Compare
February 5, 2019 21:58
|
I worked around the issues by checking out a copy of the repository from github into the container at a well-known location. This way the unit tests can run against a fresh clone of the repository and succeed. |
Sorry, something went wrong.
56a06d8 to
e5b03d4
Compare
February 5, 2019 22:45
e5b03d4 to
2e93205
Compare
February 6, 2019 00:34
|
I'm going to tease this apart into smaller bits... |
Sorry, something went wrong.
2e93205 to
21b712a
Compare
March 15, 2019 11:47
|
@Byron consider merging this. The appveyor jobs are passing, at least the ones known to pass, and there are some that are known failures; it would still be nice to get all the CI builds to green since that makes it so much easier to determine if a pull request is even worth looking into. |
Sorry, something went wrong.
|
Hi @jeking3 , thanks so much for your persistency. Right now I am very short on time and am far away from this, and any other of my open source projects, which must be frustrating for GitPython's user base. Maybe it would help if there were more collaborators - I have invited you in case this sounds feasible to you. |
Sorry, something went wrong.
|
I'll do what I can. Apart from founding a new company, I'm also involved in boost, apache thrift, and a couple other efforts. At the very least if I can get the CI builds to run clean and have folks rebase their pull requests, it would be a lot easier to qualify things in the pipeline. Thanks! |
Sorry, something went wrong.
Before:
Note that
setup.pywas not even using the contents ofrequirements.txtortest-requirements.txt. Now it does, and it properly identifies thetests-requirefield. Therequirements.txtfile declared a runtime dependency on a testing package. I'm assuming that is an error (although it could be used in production code, I don't know...) so I removed that.When I ran tox locally on Python 3.6.7 I saw a flake8 error F821 which I disabled as it looks bogus - that exception is defined in the documentation.
Added a docker container that you can use with a couple new make targets. This allows you to run python 2.7, 3.4, 3.5, 3.6, or 3.7 tox even if you are on a local branch not named "master" (some tests require this).
Finally, found and fixed the issue on CI with python 3.7 / Xenial / travis. The root cause is that in git 2.20 new behavior was introduced to stop "git fetch --tags" from clobbering local tags that have changed: git/git@0bc8d71
The unit tests expect the old behavior, so now we pass --force down if the version is 2.20 or higher (for the remote test only, the code change is in the test code). It took a while to find this because for some reason when GitCommandError returns an error code, stderr isn't captured. If it was, it would have been easier to figure this out...