andrenarchy
Introduce dev-requirements.txt
setup.cfg doesn't know about which tools I should have for development, e.g., flake8, black, isort, nose. I think we should re-introduce requirements.txt and add these tools. In the workflow file, we can also install the tools from requirements.txt.
I just noticed that readthedocs also relies on requirements.txt (and it's failing right now).
@nschloe: any objections against re-introducing it?
Perhaps we can add a note in the file that it's for readthedocs only, and can be removed once they update their infrastructure.
I understood that requirements.txt is still useful for dependencies that you need for development or CI? Like devDependencies in npm packages? For example, we wouldn't want that linters are installed when you install via pip. Is there a standard way now?
Historically, requirements.txt has been used to specify runtime requirements for the package, with instructions to pip install -r requirements.txt. Then it moved into setup.py, then setup.cfg (though the latter is a recent development). If you want to specify dev dependencies, I'd choose a name different from requirements.txt because of it's historical connotation; perhaps dev-requirements.txt is good. OTOH, I'm not aware of Python projects that are this accurate in specifying linters and such. It's a different story for test dependencies; there, tox has gained some popularity in recent years.