On 09/24/2013 06:44 AM, Nikola Đipanov wrote:
On 24/09/13 10:15, Gary Kotton wrote:
Hi,
Anyone know the root cause of:
2013-09-24 06:47:01.670 | Cleaning up...
2013-09-24 06:47:01.670 | No distributions matching the version for pyparsing>=2.0.1 (from
cliff>=1.4.3->python-neutronclient>=2.3.0,<3->-r
/home/jenkins/workspace/gate-nova-pep8/requirements.txt (line 25))
2013-09-24 06:47:01.670 | Traceback (most recent call last):
2013-09-24 06:47:01.671 | File ".tox/pep8/bin/pip", line 9, in <module>
2013-09-24 06:47:01.671 | load_entry_point('pip==1.4.1', 'console_scripts',
'pip')()
2013-09-24 06:47:01.671 | File
"/home/jenkins/workspace/gate-nova-pep8/.tox/pep8/local/lib/python2.7/site-packages/pip/__init__.py",
line 148, in main
2013-09-24 06:47:01.671 | return command.main(args[1:], options)
2013-09-24 06:47:01.672 | File
"/home/jenkins/workspace/gate-nova-pep8/.tox/pep8/local/lib/python2.7/site-packages/pip/basecommand.py",
line 169, in main
2013-09-24 06:47:01.672 | text = '\n'.join(complete_log)
2013-09-24 06:47:01.672 | UnicodeDecodeError: 'ascii' codec can't decode byte
0xe2 in position 56: ordinal not in range(128)
2013-09-24 06:47:01.673 |
2013-09-24 06:47:01.673 | ERROR: could not install deps
[-r/home/jenkins/workspace/gate-nova-pep8/requirements.txt,
-r/home/jenkins/workspace/gate-nova-pep8/test-requi
This seems to be an issue with pip not being able to find the right
version of pyparsing. This is strange as the command invocation log does
not suggest any alternative indexes are used - and it works for me.
Maybe someone from the infra team has some more insights?
PS - the unicode error seems to happen when trying to log the failure -
not the cause of it.
N.
Global requirements caps pyparsing at < 2. If software isn't in global
requirements, it's not let into the mirrors for the gate (so that shadow
dependencies don't sneak in requirements we don't support).
Which ... is exactly what happened.
cliff 1.4.5 was released, and in a patch level release bumped up a
minimum requirement a major version (pyparsing > 2 now required). This
created a wedge situation.
There are 2 options.
1) cap cliff
or
2) uncap pyparsing
I went for point 2, though it's not been tested with any of the stack,
and realistically not something we probably want to do at this stage of
release. Maybe dhellman would have other opinions once he gets online
this morning.
https://review.openstack.org/#/c/48014/ is the review in process
And to members of our community who are also maintainers of python
libraries, I'd ask that you please be really cognizant of when you move
requirements up major versions, and please us that as criteria to bump
your version numbers at least a minor level (i.e. second digit) and not
just a patch level. Integrating 100 python sources into a coherent whole
is a hard job, and anything that can make it easier would be appreciated.
-Sean
--
Sean Dague
http://dague.net
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
