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.
I have attempted to reproduce this locally and it seems to work just fine.
clark@nibbler: ~/tmp/pbr_ testing$ virtualenv -p python3 venv tmp/pbr_ testing/ venv/bin/ python3 tmp/pbr_ testing/ venv/bin/ python ~/tmp/pbr_ testing$ venv/bin/pip install -i http:// mirror. dfw.rax. openstack. org/pypi/ simple --trusted-host mirror. dfw.rax. openstack. org pbr mirror. dfw.rax. openstack. org/pypi/ packages/ 0c/5d/b077dbf30 9993d52c1d71e6b f6fe443a8029ea2 15135ebbe0b1b10 e7aefc/ pbr-3.1. 1-py2.py3- none-any. whl (99kB) ███████ ███████ ███████ █████| 102kB 675kB/s
Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/clark/
Also creating executable in /home/clark/
Installing setuptools, pip, wheel...done.
clark@nibbler:
Collecting pbr
Downloading http://
100% |██████
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.