It seems like they’re using setup.py to configure the user’s system, so that future invocations of Pip will know about their own package indexes.
There’s what I interpret as basically a different version of this, which appears to work by locating Pip’s config file and rewriting it. (And in order to search for the config file, it’s trying to use functionality from pip._internal.configuration…).
IMO this is clearly not how the system is supposed to work. Regardless of whether Pip intends to offer an API for other programs to locate or edit Pip config files, none of this makes sense to wrap into a setup.py or fit into the Setuptools framework. It isn’t actually installing usable Python code (yet). It should be provided as a separate Python script that can just be downloaded and run. (It’s not as if going through setup.py is any more secure than that!)
In this context, it seems like they’re doing it as a step in a larger sdist-building process, which would on its face seem more justifiable. But I agree that this feels quite wrong. There’s only so much that can be done automatically to try to make an sdist work on a remote machine, when you don’t control the initial state of the environment. It also doesn’t seem very polite, to me, that they use this to make Pip grab packages from separate indices that the user didn’t specify on the command line. As a user I should be at least somewhat in control of what domains my machine is connecting to for downloads; I’d expect to follow instructions in a README and explicitly add the package index URLs myself first, instead.
(This previous thread seems related?)