BUG: Fix setup.py build install egg_info, which did not previously build

[eric-wieser]

Fixes #10646

It seems the original intent was to disable builds when only the egg_info target is requested, not whenever it is one of the targets.

It's kinda gross that we're adding a second layer of (fragile) argument parsing to setuptools here, but that something to address another time.

Not a regression, but it would be nice to slip it into the next release.

[rgommers]

Still don't think such combined commands are correct usage, but this change also can't hurt. So fine with me to merge.

[charris]

Thanks Eric.

[eric-wieser]

@rgommers: I thought that too, but it's documented behavior:

$ python setup.py -h
<snip>
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

[rgommers]

@rgommers: I thought that too, but it's documented behavior:

I know, but so are all the commands we explicitly disallow. My point was not what's an "official feature" but what makes sense to use/support/allow. The only common build chaining in the wild is build install, anything else is "use at your own risk" I think.

[eric-wieser]

Unfortunately a proprietary build system I was using invokes setup.py with that incantation, and the authors seemed to think that they were justified in doing so in case state is needed between commands.

I don't buy that argument, but numpy's behavior here looks to have been unintended, so a fix seemed sensible regardless

[rgommers]

Proprietary systems, always fun :)

No the behavior was not intended to be broken, such things are pretty much dont-cares given that it's untestable.