It's not unusual for a setuptools command to have dependencies. The most common example is tests_require, but there are other applications. Often this is resolved by introspecting name of the command at runtime and constructing list for setup_requires accordingly.
With installation requirements there is more or less standard practice of having common dependencies expressed via install_requires and optional via extras_require.
I propose the similar hierarchy for setuptools commands:
setup_requires should be used for common dependencies
setup_extra_requires should be used similarly to extra_requires where keys are commands like test, install, or any other string allowed as a command name
Backward compatibility
tests_require should be an alias to setup_extra_requires['test']; if both are specified error should be issued
install_requires is independent from setup_extra_requires['install'] because it expresses package requirements, not setuptools command execution requirements
It's not unusual for a setuptools command to have dependencies. The most common example is
tests_require, but there are other applications. Often this is resolved by introspecting name of the command at runtime and constructing list forsetup_requiresaccordingly.With installation requirements there is more or less standard practice of having common dependencies expressed via
install_requiresand optional viaextras_require.I propose the similar hierarchy for setuptools commands:
setup_requiresshould be used for common dependenciessetup_extra_requiresshould be used similarly toextra_requireswhere keys are commands liketest,install, or any other string allowed as a command nameBackward compatibility
tests_requireshould be an alias tosetup_extra_requires['test']; if both are specified error should be issuedinstall_requiresis independent fromsetup_extra_requires['install']because it expresses package requirements, not setuptools command execution requirements