Comment 11 for bug 1194742

Reviewed: https://review.openstack.org/35280
Committed: http://github.com/openstack/oslo-incubator/commit/9f09474c5f8f591453e1dc5e3c1ddc3c7efd4985
Submitter: Jenkins
Branch: master

commit 9f09474c5f8f591453e1dc5e3c1ddc3c7efd4985
Author: Mark McLoughlin <email address hidden>
Date: Tue Jul 2 13:01:26 2013 +0100

    Fix issue with pip installing oslo.config-1.2.0

    Fixes bug #1194807

    Firstly, we update the oslo.config dep to 1.2.0a3 because of the issue
    with namespace packages (bug #1194742).

    But the main issue here is that if we ever added a dependency to our
    requirements.txt that had a dependency on an older version of
    oslo.config we would see the same issue thatt Nova and Quantum recently
    experienced where you end up with the oslo.config 1.1.1 code installed.
    This is because oslo.config>=1.1.0 gets pulled in as a transitive dep
    and pip gets confused. You can reproduce with e.g.

      $> pip install \
           http://.../oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3 \
           python-keystoneclient
      $> pip freeze | grep oslo.config
      oslo.config-1.2.0a3
      $> python -c 'from oslo.config.cfg import DeprecatedOpt'
      Traceback (most recent call last):
        File "<string>", line 1, in <module>
      ImportError: cannot import name DeprecatedOpt

    This is because of a bug with pip where it sees oslo.config-1.2.0a3 and
    oslo.config as two unrelated things. It should strip the version part of
    the egg= fragment before using it as a package name, but it doesn't.

    However, we can simply use the -f/--find-links pip option in our
    requirements.txt to add the tarball URL to the list of URLs considered
    and also add the oslo.config>=1.2.0a3 dependency:

      $> pip install \
           -f http://.../oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3 \
           'oslo.config>=1.2.0a3' \
           python-keystoneclient
      $> pip freeze | grep oslo.config
      oslo.config-1.2.0a3
      $> python -c 'from oslo.config.cfg import DeprecatedOpt'

    This is actually exactly the semantics we want and we go to great
    lengths in pbr to get these semantics while using a single tarball URL.
    The only downside to this --find-links strategy is that we gain an extra
    line in our requirements.txt ... but it does work around the pip bug.

    Change-Id: I6f3eb5fd2c75615d9a1cae172aed859b36b27d4c