Deprecate test command

[pganssle]

I think there's at least some agreement in #931 that we want to remove the test command. I think we should start by raising deprecation warnings pointing people at tox, the same way we've done for the upload and register commands.

The most likely stumbling block that I see is that I think a huge number of people have created their own test command that invokes their preferred test runner, pytest or whatever. Ideally we'd want to get the deprecation warning to them as well. Hopefully most of them are using TestCommand as their base class, though if we want to get really aggressive about it we could try parsing sys.argv directly.

I think we need to warn in the following situations:

1. If the setup.py test command is executed
2. If tests_require is specified
3. If aliases.test is specified in setup.cfg

It's likely that at least two of these will be specified, but I think two separate warnings would be useful.

CC: @gaborbernat @RonnyPfannschmidt @nicoddemus

[jaraco]

The pytest-runner project does subclass the test command, and there are projects actively depending on it. I do agree we want to deprecate each, and probably both together.

[di]

A bit off-topic, but do we have an overarching issue for deprecating/replacing the various incantations of setup.py? If not, would probably be good to have this, as well as some documentation about migrating on https://packaging.python.org/.

(I can create these issues if they don't already exist)

[jaraco]

do we have an overarching issue for deprecating/replacing the various incantations of setup.py?

Not to my knowledge.

[native-api]

I think there's at least some agreement in #931 that we want to remove the test command. I think we should start by raising deprecation warnings pointing people at tox

Is there, really? The feeedback there is basically that tox is a large dependency and is designed for a different use case than setup.py test.

[jayvdb]

This is a great way to kill sdists. (why have sdists if they have the same contents as wheels) How quickly the lesson of sourceforge.net has been forgotten. Or more recently Oracle changing the Term of Use of the Java downloads. IMO setuptools should be moving in the opposite direction, automatically including in sdists the test modules found using test_require or identified using pytest dry-run.

Anyways, unless setuptools also kills its plugin mechanism, someone will recreate the test command as soon as it is removed from setuptools. Maybe that is a good thing. (But if the goal is only to get that stuff out of the setuptools repo because it is hindering setuptools, why not split it off to a separate project now, rather than pretend that tox is a drop in solution)