[openstack-dev] [stable][infra] request for reviews on two requirements changes

Amrith Kumar amrith at tesora.com
Sat Apr 23 20:10:49 UTC 2016

On Sat, 2016-04-23 at 12:53 -0500, Matt Riedemann wrote:
> On 4/23/2016 8:20 AM, Amrith Kumar wrote:
> > Folks,
> >
> > Changes [1] and [2] blacklist Routes 2.3 in Mitaka and Liberty. They've
> > been cherry picked from a change that merged in master.
> >
> > I would like both changes merged so I can then make corresponding
> > changes in Trove, and then make a Trove (Mitaka) bug fix release.
> >
> > Thanks,
> >
> > -amrith
> >
> > [1] https://review.openstack.org/#/c/298486/
> > [2] https://review.openstack.org/#/c/298488/
> >
> >
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> Is this even still needed?  Trove should be using upper-constraints in 
> liberty, mitaka and newton as of [1]. And Routes in upper-constraints is 
> capped at 2.2 in liberty and mitaka.

The reason this change is being submitted is because people are advised
to use upper-constraints.txt as the versions that have been tested but
they don't always do that.

As a result, blocking in requirements.txt is also recommended.

Incidental to that, one thing that has always confused me about
upper-constraints.txt has been the notion of capping. I notice that you
say that "Routes in upper-constraints is capped at 2.2". I'm struck by
the choice of the word 'capped'. 

When I was first debugging this problem with Routes, I ran this little

        # Make a little venv for this test.
        amrith at amrith-work:/tmp$ virtualenv t1
        New python executable in /tmp/t1/bin/python
        Installing setuptools, pip, wheel...done.
        amrith at amrith-work:/tmp$ cd t1
        # then activate it
        amrith at amrith-work:/tmp/t1$ source bin/activate
        # is Routes in the venv, it won't be ...
        (t1) amrith at amrith-work:/tmp/t1$ pip freeze | grep Routes
        # create some requirements and upper-constraints files
        (t1) amrith at amrith-work:/tmp/t1$ cat requirements.txt
        Routes!=2.0,!=2.1,<=2.3.0,>=1.12.3;python_version=='2.7' # MIT
        (t1) amrith at amrith-work:/tmp/t1$ cat upper-constraints.txt
        # install with those two ...
        (t1) amrith at amrith-work:/tmp/t1$ pip install -c
        upper-constraints.txt -r requirements.txt
        Collecting Routes===2.3.1 (from -c upper-constraints.txt (line
        Collecting six (from Routes===2.3.1->-c upper-constraints.txt
        (line 1))
          Using cached six-1.10.0-py2.py3-none-any.whl
        Collecting repoze.lru>=0.3 (from Routes===2.3.1->-c
        upper-constraints.txt (line 1))
        Installing collected packages: six, repoze.lru, Routes
        Successfully installed Routes-2.3.1 repoze.lru-0.6 six-1.10.0
        # what just happened?
        (t1) amrith at amrith-work:/tmp/t1$ pip freeze | grep Routes
        (t1) amrith at amrith-work:/tmp/t1$ python --version
        Python 2.7.6
I don't think upper-constraints.txt serves as an upper bound on the
version of a library that must be used, rather as a constraint that
overrides the requirements.txt file, EVEN IF IT CONTRADICTS IT.

Above, notice that requirements.txt says <= 2.3.0 and
upper-constraints.txt says 2.3.1, well 2.3.1 got installed.

Or this ...

        (t1) amrith at amrith-work:/tmp/t1$ pip uninstall Routes
        Uninstalling Routes-2.3.1:
        Proceed (y/n)? y
          Successfully uninstalled Routes-2.3.1
        (t1) amrith at amrith-work:/tmp/t1$ cat upper-constraints.txt
        (t1) amrith at amrith-work:/tmp/t1$ pip install -c
        upper-constraints.txt -r requirements.txt
        Collecting Routes===2.1 (from -c upper-constraints.txt (line 1))
        /tmp/t1/local/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:315: SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certificate, which can cause validation failures. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning.
        /tmp/t1/local/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:120: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
          Downloading Routes-2.1.tar.gz (179kB)
            100% |################################| 184kB 2.1MB/s
        Requirement already satisfied (use --upgrade to upgrade):
        repoze.lru>=0.3 in ./lib/python2.7/site-packages (from
        Routes===2.1->-c upper-constraints.txt (line 1))
        Building wheels for collected packages: Routes
          Running setup.py bdist_wheel for Routes ... done
          Stored in
        directory: /home/amrith/.cache/pip/wheels/84/93/eb/68589a0c49b27d9b3a4965c1d2d626235a0a4e03572772810b
        Successfully built Routes
        Installing collected packages: Routes
        Successfully installed Routes-2.1
        (t1) amrith at amrith-work:/tmp/t1$
I think upper-constraints.txt doesn't cap requirements, it just
overrides it ... Is that how it is supposed to work?

> [1] 
> https://review.openstack.org/#/q/aca90168f52169afb36500d6af77723b1a707008

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160423/3660752c/attachment.pgp>

More information about the OpenStack-dev mailing list