Comment 37 for bug 1194807

Reviewed: https://review.openstack.org/35279
Committed: http://github.com/openstack/neutron/commit/7d2588935086e7afce6969ff1f44239473af9953
Submitter: Jenkins
Branch: master

commit 7d2588935086e7afce6969ff1f44239473af9953
Author: Mark McLoughlin <email address hidden>
Date: Tue Jul 2 12:25:58 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 you currently do:

      $> pip install -r quantum/requirements.txt

    then 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