Cleanup some test and coverage configuration

[cidrblock]

• Add tox, pytest and pytest-xdist to the test deps
• Update the coverage report configuraion in the pyproject.toml
• Switch the coverage source to the package name for easier troubleshooting when running `coverage run --debug trace"
• Remove all coverage files from the tox venv (.coverage and .coverage.xxx)
• Enable xdist and add necessary .pth file for xdist forks to start coverage collection

[ssbarnea]

@cidrblock I would really want to avoid this hack. What we can do to avoid it? -- i would rather use a plugin instead of it.

[cidrblock]

I'm not sure there is anyway to avoid it, I guess we could "hide" it, although I think up front here it's a little more obvious what's actually going on.

There exists the coverage-enable-subprocess python package which has no README, license and only 10 stars which I see you commented on today, but does the exact same thing.

Another implementation of the same exists here, but again not a popular project, and does the exact same thing.

Having a look at sourcegraph, it appears some people do the same, except in their github action, which would be really difficult to test locally if there was an issue.

The approach here is exactly what is suggested in the docs for coverage:

Create a .pth file in your Python installation containing:

import coverage; coverage.process_startup()

https://coverage.readthedocs.io/en/latest/subprocess.html

I don't have feeling here one way or another, but it is nice to finally know how this exactly works for coverage which should allow us to get coverage for subprocess in tests easier as long as the same interpreter is used and the env var is carried through.

Because it is interesting, pip has a pytest venv fixture where they write the file out to the new venv. I suspect we may need something like this at some point if we're running a test in a fresh venv

I'm open to suggestions, but based on the time I've spent on this, the tox approach seems like the most obvious and straight forward approach given what needs to happen for a new proc to write coverage with the config file we have.

[cidrblock]

I neglected to mention the pytest-cov project, which again is doing the same thing: https://github.com/pytest-dev/pytest-cov/blob/5295ce01c84262cec88f31255e9ac538718f3047/setup.py#L27 but seems like a heavy dep to bring in for just the pth file injection which will work fine if tox is the entrypoint.

(and because of the work you did with the combining of the coverage files from the tox venv and building the lcov file in the root, we'll get the feedback we need within VsCode)

[cidrblock]

This is out of date based on the better config in ADE and ADT, will revise at some point in the future