pmxbot IRC Log Viewer

[12:33:41] <dstufft> lifeless: https://www.reddit.com/r/Python/comments/36v5ps/pip_70_released_will_auto_build_and_cache_wheels/crhd2qw

[14:00:47] <lifeless> dstufft: cool.

[14:01:04] <dstufft> lifeless: nobody has yelled at me yet

[14:01:06] <dstufft> so that's a plus

[14:01:17] <dstufft> well someone in #openstack-infra had some logs where pip 7 broke something

[14:01:30] <dstufft> looks like openstack might need --trusted-host <mirror domain>

[14:02:52] <dstufft> lifeless: sorry it took me a few days to get it out, been bouncing between a bunch of different discussions between different people and fallout from S3 stuff

[14:03:45] <lifeless> dstufft: thats a third party CI using an untrusted pypi mirror

[14:03:50] <lifeless> dstufft: its fine

[14:03:54] <dstufft> lifeless: oh

[14:03:58] <dstufft> ok cool

[14:04:07] <lifeless> look at the url here http://15.126.198.151/76/182276/8/check/3par-iscsi-driver-master-client-pip-megatron-dsvm/a0044b2/logs/devstacklog.txt.gz#_2015-05-22_03_57_51_343

[14:04:32] <lifeless> We should check that the official CI bandersnatch mirrors are either trusted || ssl though, its a good point.

[14:04:43] <lifeless> But I think if we'd bust the world, more folk would be screaming

[14:04:53] <dstufft> yea I thought that bit was weird

[14:05:03] <dstufft> someone said it broke a thing, but nobody else was yelling

[14:05:09] <dstufft> so I wasn't sure what was going on

[14:05:14] <dstufft> makes sense it was third party

[14:12:03] <lifeless> I'm looking at status.openstack.org/zuul to see if I can ascertain all-good or not.

[14:14:30] <dstufft> fun fact, the first version of pip that supported wheels was released almost 2 years ago

[14:14:40] <dstufft> about 2 months shy

[14:17:28] <lifeless> ok I think we're good

[14:17:37] <lifeless> grenade on a nova job failed with 2015-05-22 13:43:30.721 | /opt/stack/old/devstack/lib/keystone: line 569: disable_apache_site: command not found

[14:17:47] <lifeless> which doesn't look at all pip related

[14:18:15] <dstufft> awesome

[14:18:28] <dstufft> that might be the first major pip release that didn't break openstack

[14:18:36] <lifeless> yeah ./lib/apache:function disable_apache_site {

[14:18:59] <lifeless> and everything else was green

[14:19:05] <dstufft> awesome

[14:19:09] <dstufft> good work lifeless :)

[14:20:01] <lifeless> hmm

[14:20:02] <lifeless> http://15.126.198.151/76/182276/8/check/3par-iscsi-driver-master-client-pip-megatron-dsvm/a0044b2/logs/devstacklog.txt.gz#_2015-05-22_03_57_51_344e

[14:20:08] <lifeless> erm

[14:20:09] <lifeless> http://15.126.198.151/76/182276/8/check/3par-iscsi-driver-master-client-pip-megatron-dsvm/a0044b2/logs/devstacklog.txt.gz#_2015-05-22_03_57_51_344

[14:20:37] <lifeless> ^ that is a little worrying perhaps - The repository located at pypi.python.org is not a trusted or secure host and is being ignored.

[14:21:55] <dstufft> lifeless: they might have it configured as http://pypi.python.org instead of https://

[14:22:31] <dstufft> pip will see that as an insecure origin then

[14:23:18] <lifeless> yeah

[14:23:28] <lifeless> when they pop back up on IRC we can try to debug it

[21:16:43] <tchaypo> I have a requirements.txt that says "argparse; python_version<‘2.7'"

[21:16:57] <tchaypo> when I “pip -r requirements.txt”, that’a valid env marker

[21:17:55] <tchaypo> when I “pip install .” and pbr slurps in the requirements.txt, the marker ends up going through pkg_resources/__init__.py:evaluate_marker()

[21:18:57] <tchaypo> which ends up running it through https://bitbucket.org/pypa/setuptools/src/b6e4e89191a674855e06114e8072f2449ef53347/pkg_resources/__init__.py?at=default#cl-1482

[21:19:18] <tchaypo> which doesn’t recognise the < and so I get a “not a valid environment marker” error

[21:21:17] <dstufft> tchaypo: pip and setuptools use different env marker implemetnations apparently, probably because it's not a full standard et

[21:21:53] <tchaypo> pip uses markerlib

[21:22:10] <tchaypo> (a vendored version thereof)

[21:22:28] <tchaypo> setuptools seems to have a vendored version as well, but it prefers to use its own implementation

[21:22:56] <tchaypo> but it falls back on markerlib if it can’t import parser

[21:24:08] <tchaypo> and lo

[21:24:10] <tchaypo> https://bitbucket.org/pypa/setuptools/issue/380/environment-markers-dont-support-etc

[21:39:02] <tchaypo> if I want to fix this

[21:39:15] <tchaypo> I can just hack on the pkg_resources/__init__.py

[21:39:22] <tchaypo> but is there a more formal upstream place for that?

[21:45:58] <dstufft> tchorizo: setuptools

[21:46:12] <tchorizo> <3

[21:46:31] <tchorizo> I’d update tests as well

[21:46:33] <tchorizo> except that i can’t find any

[21:49:39] <dstufft> tchorizo: fwiw we have a rule, you'll have to get a PR accepted into setuptools and once it's released inside there we'll pull it into pip by pulling in the updated setuptools

[21:53:32] <tchorizo> that’s a sensible ruke

[21:56:49] <dstufft> tchorizo: jaraco accepts PRs on github too fwiw

[21:56:54] <dstufft> github.com/jaraco/setuptools

[21:58:02] <tchorizo> that sounds painful

[21:58:09] <tchorizo> managing the two sets of code

[21:58:18] <tchorizo> but *shrug*it’s dvcs, it’s not insolvable

[22:17:35] <tchorizo> so, progress. when I egg_info, the markers are dropped in the requires file, so that’s a start.

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Friday the 22nd of May, 2015