Commit Graph

132 Commits

Author SHA1 Message Date
Slawek Kaplonski 4ddd456dd3 Add support for the pyproject.toml file in setup with constraints
In the _setup_package_with_constraints_edit name of the package was
always discovered from the setup.cfg file. But as some projects
implements PEP-621 (see [1] for the SQLAlchemy for example) it is not
enough now.
This patch adds parsing pyproject.toml file also if name is not found in
the setup.cfg file.

[1] a8dbf8763a

Closes-Bug: #2052509
Change-Id: Iee9262079d09a8bd22cd05a8f17950a41a0d1f9d
2024-02-09 15:50:16 +01:00
Clark Boylan a40f9cb91f Add option to install everything in global venvs
Since we are python3 only for openstack we create a single python3
virtualenv to install all the packages into. This gives us the benefits
of installing into a virtualenv while still ensuring coinstallability.
This is a major change and will likely break many things.

There are several reasons for this. The change that started this effort
was pip stopped uninstalling packages which used distutils to generate
their package installation. Many distro packages do this which meant
that pip installed packages and distro packages could not coexist in the
global install space. More recently git has made pip installing repos as
root more difficult due to file ownership concerns.

Currently the switch to the global venv is optional, but if we go down
this path we should very quickly remove the old global installation
method as it has only caused us problems.

Major hurdles we have to get over are convincing rootwrap to trust
binaries in the virtualenvs (so you'll notice we update rootwrap
configs).

Some distros still have issues, keep them using the old setup for now.

Depends-On: https://review.opendev.org/c/openstack/grenade/+/880266
Co-Authored-By: Dr. Jens Harbott <frickler@offenerstapel.de>
Change-Id: If9bc7ba45522189d03f19b86cb681bb150ee2f25
2023-08-02 07:07:25 +02:00
Martin Kopec ec07b343d2 Remove support for opensuse
We haven't been testing the distro for a while in CI, e.g. in
Tempest, the jobs on opensuse15 haven't been executed for a year
now.
Therefore the patch removes opensuse support from devstack.

Closes-Bug: #2002900
Change-Id: I0f5e4c644e2d14d1b8bb5bc0096d1469febe5fcc
2023-02-16 12:01:39 +01:00
Nobuhiro MIKI d266c87b1d iniset: fix handling of values containg ampersand
Attempting to set a value containing the ampersand
character (&) by iniset would corrupt the value.
So, add an escaping process.

Signed-off-by: Nobuhiro MIKI <nmiki@yahoo-corp.jp>
Closes-Bug: #1983816
Change-Id: Ie2633bacd2d761d110e6cb12f95382325c329415
2022-08-08 18:59:53 +09:00
Clark Boylan 1d5be95196 Cleanup comment that should've been removed
The previous change, I237f5663b0f8b060f6df130de04e17e2b1695f8a, removed
a SETUPTOOLS flag, but not the comment explaining why that flag was
previously set. Clean up that comment.

Change-Id: I32b0240fd56310d7f10596aaa8ef432679bfd66a
2022-05-23 08:46:50 -07:00
Clark Boylan 50e3c06ec2 Fix dbcounter installation on Jammy
There are two problems with dbcounter installation on Jammy. The first
is straightforward. We have to use `py_modules` instead of `modules` to
specify the source file. I don't know how this works on other distros
but the docs [0] seem to clearly indicate py_modules does this.

The second issue is quite an issue and requires story time. When
pip/setuptools insteall editable installs (as is done for many of the
openstack projects) it creates an easy-install.pth file that tells the
python interpreter to add the source dirs of those repos to the python
path. Normally these paths are appended to your sys.path. Pip's isolated
build env relies on the assumption that these paths are appeneded to the
path when it santizes sys.path to create the isolated environemnt.

However, when SETUPTOOLS_SYS_PATH_TECHNIQUE is set to rewrite the paths
are not appended and are inserted in the middle. This breaks pip's
isolated build env which broke dbcounter installations. We fix this by
not setting SETUPTOOLS_SYS_PATH_TECHNIQUE to rewrite. Upstream indicates
the reason we set this half a decade ago has since been fixed properly.

The reason Jammy and nothing else breaks is that python3.10 is the first
python version to use pip's isolated build envs by default.

I've locally fiddled with a patch to pip [1] to try and fix this
behavior even when rewrite is set. I don't plan to push this upstream
but it helps to illustrate where the problem lies. If someone else would
like to upstream this feel free.

Finally this change makes the jammy platform job voting again and adds
it to the gate to ensure we don't regress again.

[0] https://docs.python.org/3/distutils/sourcedist.html#specifying-the-files-to-distribute
[1] https://paste.opendev.org/show/bqVAuhgMtVtfYupZK5J6/

Change-Id: I237f5663b0f8b060f6df130de04e17e2b1695f8a
2022-05-20 10:35:18 -07:00
Ian Wienand 6b9a564622 Revert "Workaround for new pip 20.3 behavior"
This reverts commit 7a3a7ce876 and
bcd0acf6c0 and part of
f1ed7c77c5 which all cap our pip
installs.

Given the pip ecosystem can often incorporate major changes, tracking
upstream at least generally gives us one problem at a time to solve
rather than trying to handle version jumps when LTS distros update.

The new dependency resolver included some changes that disallow
setting URL's like "file:///path/to/project#egg=project" in
constraints.  Apparently the fact it used to work was an accident of
the requires/constraints mechanism; it does make some sense as the URL
doesn't really have a version-number that the resolver can put in an
ordering graph.

The _setup_package_with_constraints_edit function comment highlights
what this is trying to do

 # Updates the constraints from REQUIREMENTS_DIR to reflect the
 # future installed state of this package. This ensures when we
 # install this package we get the from source version.

In other words; if constraints has "foo==1.2.3" and Zuul has checked
out "foo" for testing, we have to make sure pip doesn't choose version
1.2.3 from pypi.

It seems like removing the entry from upper-requirements.txt is the
important part; adding the URL path to the on-disk version was just
something that seemed to work at the time, but isn't really necessary.
We will install the package in question which will be the latest
version (from Zuul checkout) and without the package in
upper-requirements.txt nothing will try and downgrade it.

Therefore the solution proposed here is to remove the adding of the
URL parts.

This allows us to uncap pip and restore testing with the new
dependency resolver.

Closes-Bug: #1906322
Change-Id: Ib9ba52147199a9d6d0293182d5db50c4a567d677
2021-08-10 14:22:35 +10:00
Dan Smith 51e384554b Add some debug to async_wait failures
This dumps some data in the case where we fail to wait for a child
pid to help debug what is going on. This also cleans up a few review
comments from the actual fix.

Change-Id: I7b58ce0cf2b41bdffa448973edb4c992fe5f730c
Related-Bug: #1923728
2021-04-15 06:16:42 -07:00
Dan Smith aa5c38727b Work around CHILD_MAX bash limitation for async
Apparently bash (via POSIX) only guarantees a small (32ish) number of
children can be started and their statuses retrieved at any given
point. On larger jobs with lots of plugins and additional work, we
may go over that limit, especially for long-lived children, such
as the install_tempest task.

This works around that issue by creating a fifo for each child at
spawn time. When the child is complete, it will block on a read
against that fifo (and thus not exit). When the parent goes to wait
on the child, it first writes to that fifo, unblocking the child so
that it can exit near the time we go to wait.

Closes-Bug: #1923728
Change-Id: Id755bdb1e7f1664ec08742d034c174e87a3d2902
2021-04-14 14:33:07 -07:00
Dan Smith 84b328c814 Default to parallel execution
Several jobs have been running in parallel since the late Wallaby
cycle, and other developers have had it enabled locally. I have heard
no async-related stability or debug-ability complaints thus far.
I think that we should convert the default to parallel early in the
Xena cycle in an attempt to spread the speed improvements across the
board, while also collecting data on a wider set of configurations.

Change-Id: I83d56c9363d481bb6d5921f5e1f9b024f136044b
2021-03-26 07:17:42 -07:00
Dan Smith 30d9bf9a6d Async task support
We have a *ton* of stuff in devstack that is very linear, specifically
the ten-ish minutes we spend loading osc to run a single API command
against something. We also generate configs, sync databases, and other
things that use one core of our worker and make our runtime longer
than it really needs to be.

The idea in this patch is to make it super simple to run some things
in the background and then wait for them to finish before proceeding
to something that will require them to be done. This avoids the
interleaving you would expect by redirecting the async tasks to a log
file, and then cat'ing that log file synchronously during the wait
operation. The per-task log file remains so it's easier to examine
it in isolation.

Multiple people have reported between 22-30% improvement in the
time it takes to stack with this. More can be done, but what is here
already makes a significant difference.

Change-Id: I270a910b531641b023c13f75dfedca057a1f1031
2021-02-09 15:57:04 -08:00
Ian Wienand 18b4251bf4 Use SETUPTOOLS_USE_DISTUTILS=stdlib for global pip installs
A new setuptools release has changed the way pip installs are done,
see [0]. With this change we switch back to using the distro
method for global pip installs.

Temporarily make grenade jobs non-voting in order to allow this
patch to be backported.

[0] http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016905.html

Change-Id: I5d8aa0e58e0409c54451b51de5eb70ba9a68d849
2020-08-31 15:01:20 +02:00
Radosław Piliszek 3cbb33e5c6 Fix python3_enable to return true
Recent regression spotted by Dmitry Tantsur.
DevStack dropped Py2 support but the now-unused-in-devstack
python3_enable got its result nastily inversed.

Change-Id: I4b37cc847a24705c4955cec2e6e45f0514705f1b
2020-06-30 17:52:10 +02:00
Jens Harbott d7a82f41e4 Drop support for python2
python2 is EOL, let's move on and only support python3.

Change-Id: Ieffda4edea9cc19484c04420ed703f7141ef9f15
2020-06-26 15:27:32 +02:00
Jens Harbott f1ed7c77c5 Use python3 pip module instead of pip binary
Focal only provides a pip3 binary, no pip3.8. Instead of working around
that with a symlink, use the module instead.

Add version information output for this variant.

Change-Id: I7af194ecc40e4d43c10ce067a661bb6ab4ca37d4
2020-06-23 08:02:52 +02:00
Radosław Piliszek be26306b4a Support extras in Glance Store install
Recent change to devstack dropped installing test-requirements [1]
However, this caused gate failures due to lack of glance-store
deps for cinder and swift support.

This patch makes devstack install relevant extras depending on
enabled features.

Additionally, relevant functions are added/fixed to make this
possible.

glance-store = glance_store (for gerrit search match)

[1] https://review.opendev.org/715469

Change-Id: I0bf5792a6058b52936115b515ea8360f6264a7c9
2020-03-30 19:53:32 +02:00
Monty Taylor 09b5b05c47 Stop installing test-requirements with projects
This is a test of installing openstack and then seeing if it works.
OpenStack components do not need test-requirements to operate,
that's why they are test-requirements.

Additionally, as we look forward to depsolver pip, this is going
to screw us because we don't apply constraints to linters, which
are expressed in - you guessed it, test-requirements.

Change-Id: I8f24b839bf42e2fb9803dc7df3a30ae20cf264eb
2020-03-27 11:22:39 -05:00
Monty Taylor c2830fb267 Revert "Run pip check at end of devstack"
This reverts commit 79b8e79488.

This is breaking things in various jobs, most notably because
we do not put constraints on linters - but we install
test-requirements which then can conflict with each other.

Change-Id: Ibc5603c61b38ce44db58fb27a27352f59123ad09
2020-03-27 11:12:31 -05:00
Monty Taylor c26dfb0d6f Run pip check at end of devstack
The new pip depsolver is coming this summer. Until it's ready,
run pip check at the end of devstack to make sure we're not
somehow installing conflicting package versions. We shouldn't
be, because of constraints, but if we are, better to know and
start figuring it out.

Change-Id: Id98f0848ff5a252d93e5f8029df2d069924d603f
2020-03-26 09:44:23 +00:00
Federico Ressi 21a10d3499 Use python3 as default python command
After Python 2 is getting unsupported, new distros
like CentOS 8 and RHEL8 have stopped providing 'python'
package forcing user to decide which alternative to
use by installing 'python2' or 'python3.x' package
and then setting python alternative.

This change is intended to make using python3 command as
much as possible and use it as default 'python' alternative
where needed.

The final goals motivating this change are:
 - stop using python2 as much as possible
 - help adding support for CentOS 8 and RHEL8

Change-Id: I1e90db987c0bfa6206c211e066be03ea8738ad3f
2020-02-17 17:03:47 +00:00
Federico Ressi 2dcbc28aba Install versioned python RPMs on RedHat distros
Set default python3 version as 3 for cases python3
is not installed before running DevStack.

Implements installation of required python3x package
for RedHat family distros with package name depending on
configurable ${PYTHON3_VERSION}. Examples:

  3 => python3 python3-devel (default one)
  3.6 => python36 python36-devel
  3.7 => python37 python37-devel

This should help in situations where there are more
than one python available for given platform and
DevStack is asked to pick one by its full 3.x version

Change-Id: I49d86bc9193165e0a41e8e8720be37d81a4e7ee0
2020-02-17 12:00:41 +00:00
Zuul 80758e6932 Merge "Always install python3 and its dev package" 2020-02-15 16:01:08 +00:00
Radosław Piliszek 29bf852396 Do not try finding pip for python2 when not required
[1] stopped installing pip for py2 when py3 is being used.

This patch makes sure we check only for py3 pip then.

Also removed some no-longer-relevant comment and
made uninstall behave the same.

Check for pip>=6 removed too.

See also [2].

[1] 279a7589b0
[2] http://lists.openstack.org/pipermail/openstack-discuss/2020-January/012182.html

Change-Id: I36ee53e57e468d760b80a7e621b90899867a8efd
2020-01-24 12:55:21 +01:00
Terry Wilson 78cf6f642a Always install python3 and its dev package
Some distros do not install python3/python3-devel with the minimal
install. F29 doesn't install -devel, and neither Centos 7 or 8
install either. This patch ensures that these packages get installed.

Ideally, PYTHON3_VERSION would be set *after* ensuring that python3
was installed, but it gets a little tricky with all of the includes.
This sets it to 3.6 as nothing uses 3.5 anymore.

Change-Id: I7bdfc408b7c18273639ec26eade475856ac43593
2020-01-22 20:03:29 -06:00
Stephen Finucane 6b6bdc7111 inc/python: Remove ability to mark packages as non-Python3
Everything in OpenStack *must* be Python 3 supporting now, which means
it's time to remove the functionality that allows us to blacklist
packages that didn't support Python 3.

Change-Id: I7c8cf538ec88bd4056b0109f19671e3d65f5da3a
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
2020-01-17 11:19:16 +00:00
Ian Wienand bcb2c30c31 Remove TRACK_DEPENDS
This was added in 2012 with I89677fd54635e82b10ab674ddeb9ffb3f1a755f0,
but I can not see it being used anywhere currently.

It's use of virtualenv's has become problematic in a python2
deprecated world, but since it is not used, remove it to avoid further
confusion.

Change-Id: I65d44d24f449436ca6229928eee2c5a021793055
2020-01-13 16:31:20 +11:00
Peter Penchev 16bccbcea4 Revert "install LIBS_FROM_GIT using python 2 and 3 where appropriate"
All the OpenStack projects should be able to run under Python 3 now so
the fallback installation of the Python 2 libraries should not be
needed any longer. This also avoids the problem of script files
installed by the libraries sometimes being overwritten by the Python 2
version leading to incorrect execution later, as discussed in
http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009226.html

This reverts commit a2eb89417f.

Change-Id: I1cdb7e4a209872f1620be556b7278879a4b86df5
2019-09-09 15:14:11 +03:00
Matt Riedemann 9b6d2f20b4 Update (git|review).openstack.org links to opendev
This updates links going to git.openstack.org and review.openstack.org
to go to their respective opendev locations to avoid redirects.

Change-Id: I78e3bb5303718962f591117f9c0ee11f2314b128
Closes-Bug: #1833256
2019-06-21 14:35:16 +10:00
Tom Barron 4db9d567d1 Safety check for python version in get_pip_command
We know empirically that some legacy gate jobs pass and appear
to be running with python3 but actually pip was invoked with
PYTHON3_VERSION unset so that they are actually ran with python2
packages.

As a followup to this discussion [1], add a safety check in the
get_pip_command function to ensure that a python version has been
set when it is invoked.

[1] https://review.openstack.org/#/c/622415/4/inc/python@283

Change-Id: I3a08406fb7d68282c6b98abb33a625821510046a
2019-05-20 06:01:35 +00:00
Matt Riedemann e03bcb2c8b Remove crusty old python 3 package version logic
If we are running with python3, just assume that any
package that is not blacklisted is available for py3
and just attempt to install it and let pip sort it out
whether it gets installed from a local or remote package.

Change-Id: Ic05d183e489320f6dfc721575d47e7e4d661f87c
Closes-Bug: #1820892
2019-04-02 10:13:13 +00:00
Zuul 8ca63acff8 Merge "Fixed support python 2 on Fedora 27" 2019-03-30 00:45:27 +00:00
Lenny Verkhovsky a30dd1cc96 Fixed support python 2 on Fedora 27
I7d16194d6ba1391ca31251d5b50cbb8de033fc38 added wrong behavour
on Fedora > 26 and Centos 7 when python3 disabled
pip should install packages in /usr/bin

Closes-Bug: #1820070
Change-Id: I3a8efbc8eb6e311db9c7347577c5d2047ba523a9
2019-03-24 11:46:45 +02:00
Matt Riedemann ddb6179b04 Ease python 3 classifier check in check_python3_support_for_package_local
This makes the grep match in check_python3_support_for_package_local
the same as check_python3_support_for_package_remote.

Change I0349de2026c49279ba7f262d5e86d37018d66326 in grenade started
setting the PYTHON3_VERSION variable, and then we recently started
using bionic nodes everywhere which means we're running python 3.6.

The etcd3gw package has a python 3 and 3.5 classifier, but not 3.6:

https://pypi.org/project/etcd3gw/

The pip_install function code that is dealing with installing py3
packages is hitting a problem installing etcd3gw if the package is
local because of the more restrictive grep in the
check_python3_support_for_package_local function, and since
PYTHON3_VERSION=3.6 now, we don't install from py3 and install
etcd3gw on python 2.7 which makes services like cinder-volume and
cinder-backup, which use etcd3gw, fail when they are running under
python 3 (they get module import errors).

This simply removes the $ restriction on the grep. Looking at the
change that added those local/remote functions:

  I243ea4b76f0d5ef57a03b5b0798a05468ee6de9b

There is no explanation for the difference, it just said:

  Also, since not many packages are classified correctly, fallback
  to looking for just "Programming Language :: Python :: 3" and
  log a message for the package to highlight the problem.

So that's what this change does.

Note that alternatives would be:

1. Update the etcd3gw package to add the 3.6 classifier and do
   a release (this should probably happen anyway).

2. Add etcd3gw to ENABLED_PYTHON3_PACKAGES but that would be a
   short-term hack workaround.

Change-Id: Icd3768870ba0f1659bb2e6f002043d975047b73e
Closes-Bug: #1820892
2019-03-19 15:04:12 -04:00
Sean Mooney c759706686 support python 3 on centos 7
when installing with python 3.6 on centos7 pip installs
packages to /usr/local/bin as it does on new versions
of fedora.

this change updates the check to include centos

Change-Id: I7d16194d6ba1391ca31251d5b50cbb8de033fc38
2019-02-28 11:24:05 +00:00
Zuul f3302dcee3 Merge "Add options for development bindep install" 2019-02-06 16:34:57 +00:00
Zuul 85e6aaf541 Merge "Fix an issue in iniset function" 2019-01-17 04:35:27 +00:00
Ian Wienand 58243f6203 Add options for development bindep install
This adds a -bindep option to the key development library install
functions.  With this option the bindep.txt file will be referenced
and the relevant packages installed.

Change-Id: I856f1f59fca49b6020920d8f859b797f3b904300
2019-01-14 16:35:12 +11:00
Yi Wang 698796f1ae Fix an issue in iniset function
Given the file to be configured, if user "stack" even doesn't have
read access, the result of configuration is not expected. iniset with
"-sudo" option will always create the section and the option which we
want to configure for each calling, no matter whether this section and
this option exist in the file or not. The root cause is the calling of
grep and ini_has_option in iniset don't use the "sudo" option.

Change-Id: I9d21322046b7be411c4c7c28fefc24894fa2e131
Signed-off-by: Yi Wang <yi.c.wang@intel.com>
2019-01-12 08:53:26 +08:00
Doug Hellmann 36377f63e3 install under python3 by default when enabled
Remove the requirement that services explicitly enable python3 support
in order to be tested under python3 when running with python3
enabled. Keep the enable_python3_package() function for backwards
compatibility, for now, since it is called in some devstack plugins.

Explicitly add swift to the set of packages that should not be installed
using python3 by default until full support is available.

Change-Id: I8ab0a7c242bbf5bf3f091f5a85a98e2f4543f856
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
2019-01-09 09:05:36 -05:00
Andreas Jaeger 67394b0241 Remove is_in_projects_txt
This function is nowhere used as confirmed by codesearch:
http://codesearch.openstack.org/?q=is_in_projects_txt&i=nope&files=&repos=

We can remove the function.

Note that usage of this function was removed in change
I843208e2e982eb04931b76f5cb4bd219fbcd70de in 2015.

This came up in context of https://review.openstack.org/619089 where
requirements/projects.txt is getting removed.

Change-Id: I487d3f9e340bd45e83245b9ca91e8e3b5ac3ae02
2018-11-24 10:18:07 +01:00
imacdonn e991f7da45 Use bash-style test for Fedora version
Old-style test fails on Ubuntu when python3 enabled, with:

.../devstack/inc/python: line 52: [: 16.04: integer expression expected

Use bash-style test, which doesn't attempt to evaluate the RHS if the
LHS evaluates to false

Change-Id: If18031ab98c9060e5825c3a8d3c647bd3705cd9c
Closes-Bug: #1796174
2018-10-04 19:42:21 +00:00
Luigi Toscano c7c67658c1 iniset: fix handling of keys with spaces
Ceph for example uses them. Creation already worked, but not
updates of existing keys.

Closes-Bug: 1774956

Change-Id: I20cb61c08079b9cd9ad56ac875525abf1442bff6
2018-06-04 11:00:08 +02:00
Zuul a0f319fc6d Merge "Automatically set LIBS_FROM_GIT based on required projects" 2018-04-19 12:44:31 +00:00
James E. Blair e1edde38ed Automatically set LIBS_FROM_GIT based on required projects
If a project shows up in zuul's required-projects list, add it
to LIBS_FROM_GIT automatically.  This way, when a user specifies
that a job requires a zuul-project, it gets used in testing, but
otherwise, it doesn't (pypi is used instead).

Also add information about what happens behind the scenes for both
LIBS_FROM_GIT and plugin dependencies.

This moves the check performed in check_libs_from_git to
a helper function which is installed for most kinds of
installations.  This means that if someone sets LIBS_FROM_GIT to
"foobar", devstack won't error anymore, as nothing is going to
try to install foobar, therefore the check won't run on that.
However, as we move to automated generation of the local config,
that error is not likely to happen.  This check was originally
added due to an error in the upper-constraints file (where a
constraint name did not match a package name).  This location of
the check would still catch that type of error.

Change-Id: Ifcf3ad008cf42d3d4762cfb3b6c31c93cfeb40db
2018-04-17 13:48:37 -07:00
Monty Taylor 236250f1c3
Rename python-openstacksdk to openstacksdk
Change-Id: Ia77163f330f674146b369dfebea56bd97820057e
Depends-On: https://review.openstack.org/554662
2018-03-23 08:27:57 -05:00
Victor Stinner b9891eea1f Fix Python3 get_python_exec_prefix on Fedora 27
On Fedora 27, the default Pytho 3 install prefix changed from /usr
to /usr/local:
https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe

Closes-Bug: #1741901
Change-Id: Id40620efdf173189df053b5d380a801092933f83
2018-01-09 11:22:39 +01:00
Monty Taylor e46f22db7f
Add workaround for openstacksdk in check_libs_from_git
python-openstacksdk does not match its pip name which is openstacksdk.
So setting python-openstacksdk in LIBS_FROM_GIT leads to devstack
thinking there is a problem.

Put in a workaround for now. It would be better to either:

  a) rename python-openstacksdk repo to openstacksdk
  b) rename the pip name for openstacksdk back to python-openstacksdk
  c) add general support in the various GIT hashes for a pip name

Change-Id: I57cf95763d54ad2060a4ce2af91c3ba18ca04db0
2017-12-03 10:21:26 -06:00
DamonLi 007f588f27 Convert to safe name in lib_installed_from_git
The 'pip list' command prints the "safe name" which converts _'s to
-'s amongst other things; e.g. glance_store becomes

  "glance-store             0.21.1.dev22      /opt/stack/glance_store"

Because people may use these more familiar "file system" names in
LIBS_FROM_GIT automatically convert names when checking if libraries
are installed.

Change-Id: I30524f80a341f38dfa794a8f629d859e85a4a448
2017-11-28 07:34:49 +11:00
rabi b5fb7fd627 Fix lib_installed_from_git
In commit f0cd9a8b08 we changed to
use column format, but it checks for zero length string and
check_libs_from_git fails.

Change-Id: I97b52b80efb33749647229a55147a08afa112dd2
2017-11-22 10:09:30 +05:30
Zuul ec31a52560 Merge "Update lib_install_from_git to use column format" 2017-11-21 20:04:33 +00:00