Just calling "virtualenv" makes a Python 2 based environment;
setuptools just dropped Python 2 support (as Python 2 reached EOL in
Jan 2020) so this has now become a breakage.
Although the Python 2 path won't work, use the abstracted command.
This should stop us having to revisit this for any future cleanups (or
switing to venv, etc).
Change-Id: I531e971b78491a9276753c0d86b04c4adbd224aa
I noticed this when debugging some grenade issues failures.
An include of grenade/functions stores the current value of XTRACE
(on) and disables xtrace for the rest of the import.
We then include devstack's "functions" library, which now overwrites
the stored value of XTRACE the current state; i.e. disabled.
When it finishes it restores the prior state (disabled), and then
grenade restores the same value of XTRACE (disabled).
The result is that xtrace is incorrectly disabled until the next time
it just happens to be turned on.
The solution is to name-space the store of the current-value of xtrace
so when we finish sourcing a file, we always restore the tracing value
to what it was when we entered.
Some files had already discovered this. In general there is
inconsistency around the setting of the variable, and a lot of obvious
copy-paste. This brings consistency across all files by using
_XTRACE_* prefixes for the sotre/restore of tracing values.
Change-Id: Iba7739eada5711d9c269cb4127fa712e9f961695
Now that we don't have namespace packages any more, editable installs
should be fine. This also means that we apply constraints to these
libraries during installation, which is important for future testing.
This is needed in order to be able to easily sanity check
LIBS_FROM_GIT, as then all libs installed from git will have pip urls
with git in them.
Change-Id: I46c3b8f943b97f912eccc7278e3e033ae67e7e31
Having behavior on your laptop diverge from behavior in the gate is
confusing. Just use constraints on every devstack run to be consistent.
Users of devstack can edit the requirements repo in order to change
these constraints locally if necessary.
Change-Id: I843208e2e982eb04931b76f5cb4bd219fbcd70de
We pull the pip constraints from the requirements repo so need to clone
that repo prior to using the constraints. In fixup_stuff.sh devstack
attempts to install packages like prettytable using the constraints. It
is also possible to need constraints before fixup_stuff.sh if tracking
depends. To deal with this clone requirements repo before any possible
use of constraints in pip_install.
Change-Id: I42e981c8c5ce1b8a57b9f6cce213065c72d6af11
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
The requirements repo has had a setup.cfg etc for a long time but only
recently started using it. As it now has dependencies, we need to pip
install it. To preserve compat with older requirements repos I haven't
changed the call to invoke update-requirements yet, as we still have
the update.py symlink.
The pbr install is moved before requirements to ensure we don't
trigger easy-install.
Change-Id: I7d7e91694c9145fac0ddab8a9de5f789d723c641
When not installing pbr from source always install the latest version of
pbr. It turns out that python-pbr is a system package that satisfies
many of our requirements files pbr requirements but breaks under
setuptools 8.0. Fix this by passing the -U flag to pip when installing
pbr so that we install the latest version of pbr always.
Note that we likely need to make this more generic to avoid other system
package leakage when installing packages not from source.
We should also probably bump our pbr requirements across the board to
reflect the new setuptools 8.0 world needs.
Change-Id: I23dd21cea37d26f879aa8d864ee7d371e70221ea
Fixes-bug: 1405318
With gerrit 2.8, and the new change screen, this will trigger syntax
highlighting in gerrit. Thus making reviewing code a lot nicer.
Change-Id: Id238748417ffab53e02d59413dba66f61e724383
This patch provides a new path for installing libraries in devstack so
that it's possible to either test with upstream released libraries, or
with git versions of individual libraries.
Libraries are added by name to 3 associative arrays GITREPO,
GITBRANCH, GITDIR. When we get to the library install phase we inspect
LIBS_FROM_GIT and look for libraries by name (i.e. "oslo.config") and
if they exist we'll clone and install those libraries from
git. Otherwise we won't, and just let pip pull them as dependencies
when it needs them.
This patch provides the conversion of the oslo libraries, including
pbr.
Devstack-gate jobs for these libraries will need to change to support
actually forward testing their content.
Change-Id: I6161fa3194dbe8fbc25b6ee0e2fe3cc722a1cea4
It is no longer used for anything, nor does it seem to be
needed in the modern world of get-pip.py.
Change-Id: I5554514dd862a2004454daf295abbcf9cf9f2bfb
libraries in openstack shouldn't be installed editable, as it
causes all manner of issues (especially complicated by the use
of namespace packages). Install these globally as part of the
devstack installation process.
Change-Id: I11acb169e74069be0618e57496ff342f9e788493
Check that function calls look like ^function foo {$ in bash8, and fix
all existing failures of that check. Add a note to HACKING.rst
Change-Id: Ic19eecb39e0b20273d1bcd551a42fe400d54e938
Address miscellaneous issues with Markdown formatting in comments which
are consumed by shocco when generating the online documentation.
Change-Id: I953075cdbddbf1f119c6c7e35f039e2e54b79078
move the infrastructure projects to a dedicated lib/infra, which
gives us access to this during grenade upgrade tests.
Change-Id: I1e832792b61d41ad290b4b2ab26fe664e710cebd
Ian Wienand