[nonameiguess]

The problem with setup.py is different. Because it can run arbitrary code, package writers go crazy and import extra dependencies, but you specify your package dependencies in setup.py, so without some out-of-band way to tell your users that the setup.py file in itself also has dependencies, package installation on machines other than your own might fail unless by sheer luck your users already had the packages being used in setup.py.

That problem doesn't apply to arbitrary configuration, but only to configuration files that represent package build and installation metadata. You do see this issue with things like Gradle, though, where your build.gradle file can represent the dependencies of the package being built, but the build file itself may have dependencies since you can run arbitrary Groovy code and import any package that can be contained in a jar file. It gets around this because Gradle itself can just download those dependencies before trying to execute the build script, which would be perfectly possible for a real Python build system, but not when setup.py is just being executed by the Python interpreter, which doesn't do dependency management and expects imports to already be available in the system import path.

[nonameiguess]

Heck, for what it's worth, even Make has this issue, as people quite often write Makefiles assuming you have a bunch of tools installed that may or may not be part of the POSIX specification. I wish I could find it now, but somewhere in the GNU Make guide book is a list of more or less "approved" utilities you're supposed to be able to safely assume are installed on any GNU based system that you can use in a Makefile, and you're not supposed to go beyond that.