5c71ebd7a9
pip doesn't have a dependency resolver. Instead, it "simply uses the
first specification it finds for a project." [1] In Train, keystone
switched from hacking 0.12.x/0.13.x to hacking 1.1.x [2]. That change
explicitly added a pycodestyle dependency for reasons that aren't
entirely clear to me, but pip's broken dependency resolution leads to
the below funkiness when trying to install the dependencies.
ERROR: flake8 2.6.2 has requirement pycodestyle<2.1,>=2.0, but you'll have pycodestyle 2.5.0 which is incompatible.
As seen below, this can be easily reproduced and seems to happen because
pip doesn't go further than one level of dependencies, meaning it knows
about the dependency on flake8<2.7.0,>=2.6.0 from hacking, but not the
dependency on pycodestyle<2.1,>=2.0 that this in-turn introduces.
$ virtualenv venv
$ source venv/bin/activate
$ (venv) cat requirements.txt
hacking>=1.1.0,<1.2.0 # Apache-2.0
pycodestyle>=2.0.0 # MIT License
$ pip install -r requirements-new.txt
Collecting hacking<1.2.0,>=1.1.0
Using cached ...
Collecting pycodestyle>=2.0.0
Using cached ...
Collecting six>=1.10.0
Using cached ...
Collecting flake8<2.7.0,>=2.6.0
Using cached ...
Collecting pbr!=2.1.0,>=2.0.0
Using cached ...
Collecting mccabe<0.6,>=0.2.1
Using cached ...
Collecting pyflakes!=1.2.0,!=1.2.1,!=1.2.2,<1.3,>=0.8.1
Using cached ...
ERROR: flake8 2.6.2 has requirement pycodestyle<2.1,>=2.0, but you'll have pycodestyle 2.5.0 which is incompatible.
Installing collected packages: six, pycodestyle, mccabe, pyflakes, flake8, pbr, hacking
Successfully installed flake8-2.6.2 hacking-1.1.0 mccabe-0.5.3 pbr-5.4.3 pycodestyle-2.5.0 pyflakes-1.2.3 six-1.12.0
The solution is simple: stop explicitly requiring this dependency and
instead rely on flake8 bringing it in.
[1] https://pip.pypa.io/en/stable/user_guide/#requirements-files
[2] I3fc591e09c1e25a3bd2a3922880772ea9617f1e3
Change-Id: Ic0991d3eeae018609be0ecbd43fa0b0b9f13d6ba
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
34 lines
955 B
Plaintext
34 lines
955 B
Plaintext
# The order of packages is significant, because pip processes them in the order
|
|
# of appearance. Changing the order has an impact on the overall integration
|
|
# process, which may cause wedges in the gate later.
|
|
|
|
hacking>=1.1.0,<1.2.0 # Apache-2.0
|
|
pep257==0.7.0 # MIT License
|
|
flake8-docstrings==0.2.1.post1 # MIT
|
|
bashate>=0.5.1 # Apache-2.0
|
|
os-testr>=1.0.0 # Apache-2.0
|
|
freezegun>=0.3.6 # Apache-2.0
|
|
pytz>=2013.6 # MIT
|
|
|
|
# Include drivers for opportunistic testing.
|
|
oslo.db[fixtures,mysql,postgresql]>=4.27.0 # Apache-2.0
|
|
|
|
# computes code coverage percentages
|
|
coverage!=4.4,>=4.0 # Apache-2.0
|
|
# fixture stubbing
|
|
fixtures>=3.0.0 # Apache-2.0/BSD
|
|
# xml parsing
|
|
lxml!=3.7.0,>=3.4.1 # BSD
|
|
# mock object framework
|
|
mock>=2.0.0 # BSD
|
|
oslotest>=3.2.0 # Apache-2.0
|
|
|
|
# test wsgi apps without starting an http server
|
|
WebTest>=2.0.27 # MIT
|
|
stestr>=1.0.0 # Apache-2.0
|
|
testtools>=2.2.0 # MIT
|
|
tempest>=17.1.0 # Apache-2.0
|
|
|
|
# Functional tests.
|
|
requests>=2.14.2 # Apache-2.0
|