tree a026986f2d74c08990cc6e5681cde42abe7319ea
parent 2ba01316f37fb2c41b7dbab4a244d712ab6ed8e0
author Matt Riedemann <mriedem.os@gmail.com> 1553022252 -0400
committer Matt Riedemann <mriedem.os@gmail.com> 1553022252 -0400

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