Open Stack

> On 8 Nov 2016, at 04:07, Tony Breeds <tony at bakeyournoodle.com> wrote:
> 
> On Sat, Sep 03, 2016 at 07:33:42PM +0200, Andreas Jaeger wrote:
>> Reviewing all the constraints work, I see that repositories have created
>> some workaround around requirements install for one of these two legimit
>> reasons - most often using tools/tox_install.sh from tox.ini for it:
>> 
>> 1) The repository is a dependency of another one and uses constraints,
>> so edit upper-constraints file and allow git install.
>> 
>> Example:
>> http://git.openstack.org/cgit/openstack/ironic-lib/tree/tools/tox_install.sh
> 
> We had a very brief discussion about this in Barcelona.  The idea being to
> create an "incubator" style script in openstack/requirements that can be the
> canonical source and easily copied out to repos that need it.  I'm not
> proposing auto syncing but it would be pretty easy to script.
> 
> We need "all projects"[1] to support constraints real soon now.  It seems like
> the majority of projects that currently do not use constraints are because
> they're also listed in constraints.
> 
> I started looking at this today using [2] as the base in the oslo.messaging
> repo  The good thing about this is it doesn't "just work"  I hit the following
> problem:
> ---
> cmdargs: ['/home/stack/projects/openstack/openstack/oslo.messaging/tools/tox_install.sh', 'https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt', '/home/stack/projects/openstack/openstack/oslo.messaging/.tox/dist/oslo.messaging-5.12.1.dev10.zip']
> <snip>
> Processing ./.tox/dist/oslo.messaging-5.12.1.dev10.zip
> Could not satisfy constraints for 'oslo.messaging': installation from path or url cannot be constrained to a version
> ---
> 
> This is because we use 'edit-constraints' to change "oslo.messaging===5.12.0" to
> "-e file:///home/stack/projects/openstack/openstack/oslo.messaging#egg=oslo.messaging"[3]
> 
> Which doesn't match because we're installing from an sdist.
> 
> For development installs like this what we really want is a way to say
> constrain all my requirements but allow this library to be unconstrained don't
> we?  That seems to me what we're saying in [3].  When I'm working locally I do
> something like:
> 
> ---
> pip install -c https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt \
>            -r requirements.txt -r test-requirements.txt
> pip install .
> ---
> 
> This is all leading me to think that we should just remove the constraint on
> $library which can be done with something like:
> --- [4]
> #!/usr/bin/env bash
> 
> # Client constraint file contains this client version pin that is in conflict
> # with installing the client from source. We should remove the version pin in
> # the constraints file before applying it for from-source installation.
> BRANCH_NAME=XXX
> CLIENT_NAME=XXX
> 
> set -e
> 
> CONSTRAINTS_FILE=$1
> shift
> 
> localfile="${VIRTUAL_ENV}/upper-constraints.txt"
> if [[ $CONSTRAINTS_FILE != http* ]]; then
>    CONSTRAINTS_FILE=file://$CONSTRAINTS_FILE
> fi
> 
> curl $CONSTRAINTS_FILE -k -o $localfile
> sed -i~ -e "/^${CLIENT_NAME}===/d" $localfile
> 
> pip install -U -c$localfile $*
> ---
> 
> Using openstack_requirements is the "right" thing to do and we could still use
> edit-constraints $localfile -- $CLIENT_NAME ""
> do delete the entry but it seems like wasted work to me

I believe sed is the way to go. There is not much we get from edit-constraints at this point, and it untangles the script from zuul-cloner that would be needed to fetch requirements repo.

It seems like the way to go. Wanna propose a patch for a repo (oslo.messaging) to iterate on it in gerrit?

Ihar