Daniel Hahler

> The only thing left to settle is to find a way for the coverage reports of `loguru/` and `tests/` to be separated, and that CI checks do not fail...

> So, with these changes, coverage of the project is no longer checked? That's > problematic. :/ That was a bug, should be fixed now. > So, what about some...

It would be a useful feature for codecov to allow for an extra status, that would allow to handle tests separately: codecov/project would only look at "loguru/*" then, but "codecov/tests"...

As for now, using the flags this would get reported in the comment differently, similar to how it looks on https://codecov.io/gh/Delgan/loguru/compare/acaeeb31689b75a003bb378f46de12f3ebfcacd2...820e180bafd1d252f1fb66d10eaa5600e478ee76 already.

> I don't understand. How does using `coverage` relate to writing a custom `pytest` plugin checking called functions? How do you define "called functions"? Is it about test functions only?...

But for now I think this PR is good by itself, and we should iterate based on what comes up.

..but the codecov config should be changed to not require 100%, but just the current percentage (i.e. it does not decrease). I think you have this configured for the project...

> If the code of loguru/ is not properly covered, the CI job has to fail, like this is done currently. Travis does not fail - only codecov complains; like...

I would not add a config option for this: after all this is a config that the user is meant to make (globally). If it was particular useful in special...

> It has been like this for roughly 12 years, so it should be backwards compatible IMO You have a point there, but I would consider it to be just...