It would be useful to disable the codecov comments on PRs, it is spammy (both email and notificationsl) and does not add any real value. We still have the action that can fail if coverage fails. I did this on several projects, is one line like https://github.com/pycontribs/jira/blob/master/codecov.yml#L2

I'd accept a PR to add tox. Although I'd prefer a solution to run GH actions locally.

I like the codecov reports. I wouldn't want to enforce coverage at this point.

@willmcgugan: I have a little experience working with tox and I'd be happy to add a configuration if you like. I'm interested to know more about what you mean by

I'd prefer a solution to run GH actions locally.

though. Do you mean you'd like to run whatever the GH actions run locally or do you mean you'd like to trigger a GH action from a local testing environment? 🤔

This tool can run GH Actions locally. I'm not sure how practical that is, but it's worth investigating. Otherwise, tox is a reasonable solution.

@willmcgugan: I'll give act a look and report back here then. For comparison, in my own project I'm running tox through Poetry in a GH action quite nicely.

- name: Test
  run: |
    source $HOME/.poetry/env
    poetry run tox -q --parallel=auto

@willmcgugan: So, I went ahead and installed/ran act locally and the results are, to put it mildly, a little confusing...

$ act pull_request
...
[Test Rich module/build-6] ⭐  Run Set up Python ${{ matrix.python-version }}
[Test Rich module/build-6]   ☁  git clone 'https://github.com/actions/setup-python' # ref=v1
[Test Rich module/build-5]   🐳  docker cp src=/home/tucker/.cache/act/actions-setup-python@v1 dst=/actions/
[Test Rich module/build-4]   🐳  docker cp src=/home/tucker/.cache/act/actions-setup-python@v1 dst=/actions/
[Test Rich module/build-6]   🐳  docker cp src=/home/tucker/.cache/act/actions-setup-python@v1 dst=/actions/
[Test Rich module/build-4]   ❌  Failure - Set up Python ${{ matrix.python-version }}
Error: lstat /home/tucker/.cache/act/actions-setup-python@v1/.gitignore: no such file or directory

Go ahead and cd to /home/tucker/.cache/act/actions-setup-python@v1/ to discover...

$ git status -sb
## HEAD (no branch)
 D .gitignore

So, somehow this tool cloned something and then only copied part of the repo? 🤔 Looks like it might be related to nektos/act#198 and nektos/act#325 (which has not yet been resolved). That doesn't seem to me like the sort of thing that's good to work around, so I don't know if act is the best fit for local testing for now.

As for using tox, your current Makefile setup seems really clean and simple to me. make also has the advantage of being nearly ubiquitous. The one advantage I see for adding tox is that if you have multiple Python interpreters installed you'll be able to run local tests for all of those versions.

Your CONTRIBUTING.md already has instructions for installing other dependencies like pytest and poetry, so adding tox doesn't seem too onerous to me. That said, a tox-centric workflow would encourage a few changes...

I propose the following.

1. Add tox and tox-gh-actions to pyproject.toml's tool.poetry.dev-dependencies section.
2. Add a tox.ini file with environments with their own dependencies for
   • tests
   • formatting
   • type checking
   • docs
3. Remove requirements-dev.txt.
4. Change the Makefile to invoke tox via poetry run ....
5. Change .github/workflows/pythonpackage.yml to invoke tox via poetry run ....
6. Change CONTRIBUTING.md's documentation to reflect the above

    ## Development Environment
   
    To start developing with Rich, first [install `poetry`](https://python-poetry.org/docs/#installation), and then run the following
   
        poetry install

   after which developers should be able to either run make test or poetry run tox ... themselves.

The gist is that you should end up with a workflow where devs

• don't have to manage virtual environments directly themselves,
• can use poetry as a single entry point to the development workflow,
• and if they have the right interpreters installed, test against multiple Python versions locally.

If you're cool with this, feel free to assign this issue to me and I'll get started ASAP. If you think it's too much and you'd prefer to keep the current Makefile workflow I wouldn't blame you at all. 😅