pbr does not honor PIP_INDEX_URL or the -i flag to `pip install`

[Rotem]

This causes PBR to fail in environments using internal pypi index servers

[Clark Boylan (cboylan)]

I have attempted to reproduce this locally and it seems to work just fine.

clark@nibbler:~/tmp/pbr_testing$ virtualenv -p python3 venv
Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/clark/tmp/pbr_testing/venv/bin/python3
Also creating executable in /home/clark/tmp/pbr_testing/venv/bin/python
Installing setuptools, pip, wheel...done.
clark@nibbler:~/tmp/pbr_testing$ venv/bin/pip install -i http://mirror.dfw.rax.openstack.org/pypi/simple --trusted-host mirror.dfw.rax.openstack.org pbr
Collecting pbr
  Downloading http://mirror.dfw.rax.openstack.org/pypi/packages/0c/5d/b077dbf309993d52c1d71e6bf6fe443a8029ea215135ebbe0b1b10e7aefc/pbr-3.1.1-py2.py3-none-any.whl (99kB)
    100% |████████████████████████████████| 102kB 675kB/s
Installing collected packages: pbr
Successfully installed pbr-3.1.1

Can you provide more details on how PBR isn't respecting these variables? They should be handled by pip completely external to PBR.

[Rotem (vmalloc)]

The scenario as I recall is this:
1. Set up a private index (e.g. with devpi)
2. Upload an older version of pbr to that index
3. Create a python package with pbr
4. Run pip install -e ./package -i <your index url>

The expected behavior is for the *older* version of pbr to be used -- however what we experienced is that since pbr downloads its egg directly before proceeding, it attempts to take it from the global pypi for some reason.

Having said that it's been 10 months so it's entirely possible this has already been fixed.