On 10/01, Stephen Finucane wrote:
Another tox 4 PSA. It turns out the tox 3 was not using the command in '[tox] install_command' when installing the package under test. tox 4 does, which means overriding '[tox] install_command' to include a constraints file (-c) will prevent you installing any requirement that is listed in the upper-constraints file, even if said requirement is the thing you're currently working on. This applies to all libraries (e.g. oslo.db, python-cinderclient) but not the services (cinder, nova) since those aren't included in upper-constraints.
The "correct" way to respect upper-constraints is to provide them in 'deps' alongside the requirements file(s), e.g.
[testenv] deps = -c{env:UPPER_CONSTRAINTS_FILE:https://releases.openstack.org/constraints/upper/master} -r{toxinidir}/requirements.txt -r{toxinidir}/test-requirements.txt
This will cause tox to install all of the package's dependencies first *with* constraints before installing the package itself *without constraints*. There is a bug report open against pip to change this behaviour [1], but it's been sat there for over two years with no activity so I wouldn't rely on this.
Stephen
Hi Stephen, In my past experience with Cinder tox honored the "install_command" just fine, the problem was actually when using "usedevelop = True" and setting the constraints in deps. We ended up adding a comment in our tox to prevent people from trying to move the constraints to "deps", as that created problems. This is the comment present in Cinder's tox.ini: # NOTE: Do not move the constraints from the install_command into deps, as that # may result in tox using unconstrained/untested dependencies. # We use "usedevelop = True" for tox jobs (except bindep), so tox does 2 # install calls, one for the deps and another for the cinder source code # as editable (pip -e). # Without the constraints in the install_command only the first # installation will honor the upper constraints, and the second install # for cinder itself will not know about the constraints which can result # in installing versions we don't want. # With constraints in the install_command tox will always honor our # constraints. Has this double requirement installation changed? Will it work fine now in the scenario described in our note? Cheers, Gorka.