make constraints opt in at the test level

Instead of running a whole additional test matrix for constraints /
non-constraints, we should consider tox -e py27 the interface for
running unit tests with python2.7, and exactly which dependencies are
installed (a range with *-requirements, or an exact version with
upper-constraints) is an implementation detail which can be opted into
by each project if they feel it is appropriate.

Change-Id: I118831c5e7cdb5de9ae23387b6af92869cca6827
This commit is contained in:
Sean Dague
2016-01-13 15:25:21 -05:00
parent c7fd77e0f9
commit 3687003d13
+11 -19
View File
@@ -15,11 +15,6 @@ Projects which are compatible with Python 3 must also be able to do:
- Unit tests for python3.4
Projects may optionally also support:
- Constrained unit tests for python2.7
- Constrained unit tests for python3.4
Specific commands
-----------------
@@ -40,11 +35,6 @@ Projects which are compatible with Python 3 must also be able to do:
- tox -epy34
Projects desiring to support constrained unit tests must support:
- tox -epy27-constraints
- tox -epy34-constraints
Requirements Listing
--------------------
@@ -54,6 +44,17 @@ If there are requirements that are specific to python3 or pypy support,
those may be listed in requirements.txt or test-requirements.txt using
environment makers.
Constraints
===========
The requirements project maintains a set of constraints with packages pinned
to specific package versions that are known to be working. The goal is to
ease the diagnosis of breakage caused by projects upstream to OpenStack and
to provide a set of packages known to work together.
Projects may opt into using the constraints in one or more of their
standard targets via their tox.ini configuration.
Virtual Environment Management
------------------------------
@@ -69,15 +70,6 @@ stream collection. This is useful for aggregating and displaying test output.
In support of that, the oslotest library is built on top of testtools,
testscenarios and fixtures.
Constraints
===========
The requirements project maintains a set of constraints with packages pinned
to specific package versions that are known to be working. The goal is to
ease the diagnosis of breakage caused by projects upstream to OpenStack and
to provide a set of packages known to work together. Running constraints
enabled jobs in addition to the main tests is optional and left up to
individual projects to decide.
Project Configuration
---------------------