There seem to be a few other places where we are doing this. Want to kill them all?

$ grep -r '\.message'
package.py:            raise ValueError("In package %s: %s" % (self.name, e.message))
package.py:            tty.msg(e.message)
package.py:                    e.message)
cmd/__init__.py:        tty.error(e.message, e.string, e.pos * " " + "^")
cmd/__init__.py:        msgs = [e.message]
mirror.py:                "Error while fetching %s" % spec.cformat('$_$@'), e.message)
config.py:        message = '%s: %s' % (location, validation_error.message)
error.py:        self.message = message
error.py:        tty.error(self.message)
error.py:        msg = self.message
error.py:        args = [repr(self.message), repr(self.long_message)]
error.py:        return type(self), (self.message, self.long_message)
build_environment.py:            tty.msg(e.message)
build_environment.py:            out.write('%s: %s\n\n' % (self.name, self.message))
build_environment.py:        return self.message + self.long_message + self.traceback
build_environment.py:            self.message,
database.py:                        tty.debug(e.message)
__init__.py:    tty.die('while initializing Spack RepoPath:', e.message)
spec.py:            raise InconsistentSpecError("Invalid Spec DAG: %s" % e.message)
spec.py:                    e.message = ("Conflicting conditional dependencies on"
spec.py:                e.message = fmt.format(
spec.py:        super(SpecParseError, self).__init__(parse_error.message)
repository.py:                         e.message,

This is the problem with unit tests. No one ever remembers to test things that raise an error.

@adamjstewart I checked those: if I didn't miss something everything else should be derived from SpackError, which has indeed a message member. I agree that a refactoring of that class that mimics what Exception did in PEP352 would be a nice one to have, but maybe in another PR?

Uh, what's up with codecov?

Uh, what's up with codecov?

If you look at the last 50 commits or so, most report that Travis failed altogether. Some of the failing commits report a small amount of coverage (like 54%) while all of the commits that passed report what you would expect (74%).

I have a theory. I believe we have Travis configured in such a way that if a new commit is added, we kill any remaining jobs from previous commits, correct? Perhaps we are reporting back some coverage, but then Travis kills the job before all of the tests finish, resulting in a smaller than expected coverage percentage.

Travis also seems to be more flakey than usual. I've had to restart jobs on some commits 3 times before they all finally passed. This is affecting the majority of new PRs. I wonder if this is related.

If you look at the last 50 commits or so, most report that Travis failed altogether. Some of the failing commits report a small amount of coverage (like 54%) while all of the commits that passed report what you would expect (74%)

True. But then shouldn't we expect the opposite behavior here? I mean: if I branched from develop on a commit that reports 54% coverage, I would expect this PR to report 74% and a (fictitious) +20% in coverage. After all Travis finished on the PR...