There's a lot of value in being able to run a package's test suite once installed to verify that the integration has been done correctly. If setuptools had a way for the setup.py to say what files are needed for the test suite, then there could be an optional command to install those files too. Once setuptools has installed them, they can be packaged by the distribution packager, and the test suites ran on the target system.
Generally speaking, setuptools is moving out of the business of installing anything at all in favor of a role as a pure build tool, with the installation functions pushed to front-end tools like pip.
I am not sure I follow what you are posing perfectly, but the direction in packaging these days is to try to move things towards well-defined interfaces and metadata. In that light, it sounds like maybe you would propose to have a way to mark (perhaps in an sdist) which parts of a package are tests, and possibly how to run them? That might be a good idea, but it will probably require a PEP, and we've got a decent backlog in writing out specs for the current status quo (e.g. getting PEP 517 and its ilk to feature parity with the old setuptools-only workflow).
Most helpful comment
Generally speaking,
setuptoolsis moving out of the business of installing anything at all in favor of a role as a pure build tool, with the installation functions pushed to front-end tools likepip.I am not sure I follow what you are posing perfectly, but the direction in packaging these days is to try to move things towards well-defined interfaces and metadata. In that light, it sounds like maybe you would propose to have a way to mark (perhaps in an sdist) which parts of a package are tests, and possibly how to run them? That might be a good idea, but it will probably require a PEP, and we've got a decent backlog in writing out specs for the current status quo (e.g. getting PEP 517 and its ilk to feature parity with the old setuptools-only workflow).