devstack/lib/infra
Robert Collins 7ebe8e0751 Don't install pbr in a venv
Because PIP_VIRTUAL_ENV was set for the installation of requirements,
and left around in scope, the installation of pbr no longer happened
in a global context, it instead landed inside the virtual
env. Unsetting the variable after requirements install gets us back to
where we expect.

This was an unintended side effect of the requirements-venv patch.

Change-Id: I2c4cb4305fec81a5fd237edabee78874ccd0da22
2015-06-23 06:31:02 -04:00

62 lines
1.5 KiB
Bash

#!/bin/bash
#
# lib/infra
#
# Functions to install infrastructure projects needed by other projects
# early in the cycle. We need this so we can do things like gate on
# requirements as a global list
# Dependencies:
#
# - ``functions`` file
# ``stack.sh`` calls the entry points in this order:
#
# - install_infra
# Save trace setting
XTRACE=$(set +o | grep xtrace)
set +o xtrace
# Defaults
# --------
GITDIR["pbr"]=$DEST/pbr
REQUIREMENTS_DIR=$DEST/requirements
# Entry Points
# ------------
# install_infra() - Collect source and prepare
function install_infra {
local PIP_VIRTUAL_ENV="$REQUIREMENTS_DIR/.venv"
# bring down global requirements
git_clone $REQUIREMENTS_REPO $REQUIREMENTS_DIR $REQUIREMENTS_BRANCH
[ ! -d $PIP_VIRTUAL_ENV ] && virtualenv $PIP_VIRTUAL_ENV
# We don't care about testing git pbr in the requirements venv.
PIP_VIRTUAL_ENV=$PIP_VIRTUAL_ENV pip_install -U pbr
PIP_VIRTUAL_ENV=$PIP_VIRTUAL_ENV pip_install $REQUIREMENTS_DIR
# Unset the PIP_VIRTUAL_ENV so that PBR does not end up trapped
# down the VENV well
unset PIP_VIRTUAL_ENV
# Install pbr
if use_library_from_git "pbr"; then
git_clone_by_name "pbr"
setup_lib "pbr"
else
# Always upgrade pbr to latest version as we may have pulled it
# in via system packages.
pip_install "-U" "pbr"
fi
}
# Restore xtrace
$XTRACE
# Tell emacs to use shell-script-mode
## Local variables:
## mode: shell-script
## End: