Add missing files to gitignore

[ssbarnea]

• add temp files to gitignore so git does not report dirty after running tests
• update tox config to report errors if after running tests there
  are untracked files or modified tracked files (dirty)

[jaraco]

For these meta-project concerns, I've traditionally used the jaraco/skeleton project to track those concerns (and consolidate best practices). I haven't yet adopted the skeleton for this project as I'm unsure if it's going to become a project on its own (ideally, it will become the official implementation under Setuptools, but we're not there yet).

Thinking about the two concerns:

.gitignore

I try not to keep .gitignore files that are just mutated copies of every other .gitignore file. I like to reserve the .gitignore file for settings that are project-specific. For settings that are language or system or editor environment specific, I recommend those settings be made in the global or system files. For example, I keep a ~/.gitignore_global containing the proposed ignore items (and more), so I can (and do) manage hundreds of Python projects without having to worry about managing the always-ignored artifacts.

Sometimes I do accept these contributions to projects just because I know it makes things easier for some users and that the tooling and guidance doesn't make it easy to follow the practices I do, so many developers rely on each project keeping a copy of the ignores (or employ some tooling to manage them).

tox-extra

This test seems like a useful one to have. It would be really useful in those cases where I add a new file to the local project but forget to include it in the commit, so tests pass locally but the functionality is completely missing when pushed upstream.

However, I feel the approach of a tox plugin is not a good fit for this behavior for a couple of reasons:

• Tox is responsible for a lot more than just running the tests. Tox is frequently used to orchestrate other behaviors, like checking lint or checking perfermance or finalizing releases or cutting releases or in some cases, orchestrating environments for other purposes. It's non-obvious to me that tox could even know when these checks are safe to run.
• I would expect this check to be performed either as part of running the test suite (a pytest plugin) or as a pre-commit check.

Additionally, I'm a little concerned about the 'tox-extra' package. It currently advertises to perform "a few extra checks" and then lists just the one. That makes me think it may add more checks in the future that aren't relevant to whatever projects might have adopted it.

I'd be much more open to a routine that could be explicitly enabled, not implicitly enable other things, run in the proper environments, and run at the most useful time. A pre-commit hook, pytest plugin, or standalone executable would all provide better fidelity in these regards.

Thanks for alerting me to this functionality, though.