People can leave their devstack installs around for a long time, and
in the mean time new versions of pip can be released.
The current check does not download a new version if an old one
exists. We want to check for new versions, but we also don't want the
gate jobs trying this sometimes unreliable fetch.
So add a flag-file that tells devstack if it downloaded get-pip.py
originally. If so, on each run check for a new version using curl's
"-z" flag to request only files modified since the file's timestamp.
Change-Id: I91734528f02deafabf3d18d968c3abd749751199
Closes-Bug: #1429943
We updated other usage of sudo to pass -H when installing pip things,
to avoid creating a .cache directory in $STACK_USER's $HOME that is
owned by root. get-pip.py also ends up creating a ~/.cache, so we
need to update sudo usage there as well.
Closes-bug: #1405626
Related-bug: #1405732
Change-Id: If791b9b25d6a4280dab19117004184e57e78d038
This reverts commit 3b782d304ec2073a6406c37b9e1a76c8aecfc9a3.
The blockers for setuptools 8 compatibility should all be resolved
now.
Change-Id: I6d2d63746f98f0f885816395f36022a2706fb9c5
Latest release of setuptool 8.0 made several versions used in
requirements.txt of OpenStack projects invalid. Instances:
* SQLAlchemy>=0.8.4,<=0.8.99,>=0.9.7,<=0.9.99 in oslo.db 1.2.0
* python-neutronclient 2.3.9.40.g9ed73c0 in openstackclient
Cap '<8.0' is set as a temporary fix until a better solution
comes up.
Change-Id: I4cfe2e4c86474ec9bf69a3c2007c0277288ea2b6
Currently pip will get the package from the https://pypi.python.org server.
For CI, it's a problem as Internet connection can be down,
the pypi server down, etc...
The usecase is for a company/user that maintain a local pypi mirror
and give the option to use this server instead of the official one
Change-Id: I83aac4646cb78827a92c9636d78238f8a6118642
Implements: blueprint support-local-pypi-server
Support for .dist-info directories was added in setuptools 0.6.28.
At this moment, Ubuntu Precise 12.04 provides setuptools 0.6.24
which is too old for our needs.
Six is installed from wheel which uses the .dist-info directory.
For six to be found, we need to install setuptools >= 0.6.28.
Updating setuptools to the latest version using pip will provide use
the needed version to make six discoverable.
Closes-bug: #1326811
Change-Id: I761d0aeb2b8b593cee38d512afc8fed6a2d1fe37
curl dying ends up being a really unclear failure condition, and
hard to fingerprint in the gate. We should make this much more
explicit when we die.
Also, don't trust the upstream filename, because all the rest of
our logic would break if it changes anyway.
Change-Id: Ibc2a96b33471d24c597af0d7af896fb10523156f
get-pip.py is now on a CDN, and is the prefered way to get pip.
Remove the default path of using pip tarballs from pypi and use
get-pip.py on from here on.
Closes-Bug: #1326539
Change-Id: I0661f7c6913ba6b3e1d00b30e22740d150bfd060
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
devstack-gate wants to pre-cache and then use get-pip, but we can't
throw the flag currently. Make the flag default settable via env vars.
Change-Id: I661b52670b6ce494666cbdd611e4eee6b96c8321
Partial-Bug: #1254275
Run ./stack.sh will dump ~400 lines of information, because of
tar xvfz pip-*.tar.gz, and python setup.py install.
We'd better mute stdout for the two steps, to make console cleaner
Change-Id: Icf87947e020acb48d8cbe4cdcc1641f060e50f6d
'set -o errexit' recently added to the pip installer script, which causes
the script fail when it does not able to find an already installed pip.
This change handles the situation when pip is not installed.
Change-Id: I18a42d13c4be6699db21ec5b6a095a88a199912d
stack.sh invokes some helper scripts as separate processes, rather than
by source'ing them. As with stack.sh itself, abort immediately on the
first error, so that errors don't compound and result in confusing error
messages. If one of these helper scripts aborts, stack.sh itself will
also abort in the usual manner.
Due to the change in behaviour, tweak some mv invocations to ensure that
they don't trigger false failures.
As with stack.sh itself, also enable xtrace so we can see exactly what's
happening. In particular this allows us to see the cause of any
premature termination due to a command failing whilst errexit is
enabled.
Change-Id: I7a55784c31e5395e29ab9bbe2bb112b83b9be693
pip 1.4 can handle the distribute/setuptools upgrade sequencing
appropriate. So it turns out all we need to upgrade is pip, and then the
rest will fall in to place. This will still not fix the packages vs. pip
interactions, but we don't to muck with the system setuptools packages
at all.
Change-Id: I99220ccc190798c3eb77bb2361abc6606bd546b4
* Add tools/fixup_stuff.sh to fix prettytable and httplib2 install
with pip 1.4+
* Cache downloads properly in tools/install_pip.sh
Change-Id: I482590cb91f7a10c1436bc9015afd572ac1cc73e
Install a known working recent version of pip that handles installation
dependencies more correctly than before. Extract to a separate script
so it can be used apart from stack.sh.
* Install distro setuptools if it not already present
* Install pip from source tarball as get-pip.py proved to be unreliable
* Remove python-distribute and python-pip from all prereq files,
move python-setuptools to 'general'
* Remove the earlier unfubar_setuptppls() call that attenpted to fix this
* Only update requirements.txt when no changes in repo
Tested on Precise, F18 and CentOS6.
* Fedora and RHEL allow pip to install packages ON TOP OF RPM-installed
packages. THIS IS BROKEN. And is one reason we have to be so picky
about order and so forth.
Change-Id: Ibb4b42119dc2e51577c77bbbbffb110863e5324d
