This has been failing as of 2018-10-23 while installing gcc with
this message:
==> Installing numpy dependency: gcc
==> Downloading https://homebrew.bintray.com/bottles/gcc-8.2.0.high_sierra.bottl
######################################################################## 100.0%
==> Pouring gcc-8.2.0.high_sierra.bottle.1.tar.gz
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink include/c++
Target /usr/local/include/c++
already exists. You may want to remove it:
rm '/usr/local/include/c++'
To force the link and overwrite all conflicting files:
brew link --overwrite gcc
To list all files that would be deleted:
brew link --overwrite --dry-run gcc
Possible conflicting files are:
/usr/local/include/c++ -> /usr/local/Caskroom/oclint/0.13.1,17.4.0/oclint-0.13.1/include/c++
This should increase coverage for subprocesses, where previously
`source` paths were used only from the config file, but not the initial
`--source` argument.
Given that our guidelines demand that the CI have already passed, it seems
wasteful to run all those jobs again for the exact same commit.
As discussed in https://github.com/pytest-dev/pytest/pull/3906#issuecomment-417094481,
this will skip the "test" stage when building a tag for deployment.
doctesting: remove changedir
With coverage 5 we could use COVERAGE_RCFILE to make it find the
.coveragerc, or we could add `--rcfile` to _PYTEST_TOX_COVERAGE_RUN, but
I've thought that this should not be the job that has to test if
`--pyargs` actually works.
- Skips pypy for coverage, reports only py37 to coveralls
- tox: allow for TOXENV=py37-coverage
- tracks coverage in subprocesses, using coverage-enable-subprocess, and
parallel=1
- removes usedevelop with doctesting to match `--source` being used with
coverage
- keep coveralls for now, used with AppVeyor
Travis was not successfully installing numpy with python<=2.6,
python<=3.3, or PyPy. I decided that it didn't make sense to use numpy
for all the tests, so instead I made new testing environments
specifically for numpy.
While I agree this is *far* from ideal, IMHO It is better to ignore them for now otherwise we hamper contributors with unrelated errors.
We should fix this before the next release.
#1989