Log file Viewer

[00:10:02] <unstable> nevermind, I just discovered pyxmlsec fails on x64 systems, and the solution is pyxmlsec-next

[02:05:50] <rodguze> pip install <some package> succeeds while pip install -r requirements.txt to install the same package fails with “Could not find downloads that satisfy the requirement”. Does anyone know what could be causing this behavior?

[09:11:44] <stuples> hi

[09:17:10] <ronny> hi

[09:21:53] <stuples> I realise this is a big question. But I've been looking at https://pypi.python.org/pypi/ and I was wondering if there is a way I can grab the PKG-INFO that sits inside each of the packages?

[09:22:51] <stuples> I could download *every* package and unpack them, and pull them out. But I was wondering if there is an easier/less instensive way?

[09:28:42] <stuples> I guess what I'm asking is; is there a straightforward way of looking at the meta-info (PKG-INFO) of a package?

[09:53:10] <stuples> i'll be back in a bit, but i'll probably download all the packages and extract the meta-info

[17:17:20] <JoeHazzers> i'm having trouble using pip behind a firewall. i have a proxy (which works with curl) that pip refuses to use

[17:17:45] <JoeHazzers> to the effect of

[17:17:46] <JoeHazzers> Could not fetch URL https://pypi.python.org/simple/pip/: <urlopen error Tunnel connection failed: 403 Forbidden>

[17:20:04] <Ivo> JoeHazzers: you're using --proxy ?

[17:20:17] <JoeHazzers> yep

[17:21:20] <Ivo> well a proxy isn't going to work well with https anyway

[17:21:59] <Ivo> you could try using --index-url with http://pypi.python.org/pypi/

[17:22:10] <Ivo> or /simple/

[17:23:01] <dstufft> it uses a CONNECT proxy

[17:23:03] <dstufft> for https

[17:26:39] <Ivo> So maybe the proxy doesn't implement HTTPS tunneling

[17:27:18] <JoeHazzers> and over HTTP?

[17:27:38] <Ivo> ...is fine?

[17:27:51] <JoeHazzers> nope

[17:27:59] <JoeHazzers> this proxy doesn't support CONNECT, it seems.

[17:33:27] <Ivo> http proxy shouldn't use CONNECT afaik..

[17:35:22] <dstufft> http does not correct

[17:35:49] <dstufft> http://pypi.python.org/pypi/ will redirect to https though

[17:36:36] <dstufft> you might need to set the envvar to HTTPS_PROXY = http://youproxy/

[17:36:47] <Ivo> dstufft: how about the simple one

[17:37:08] <dstufft> Ivo: all of PyPI redirects

[17:37:21] <dstufft> we redirect at the CDN edges

[17:37:25] <dstufft> before it even gets to pypi

[17:37:42] <Ivo> so does pypi exist on http anymore?

[17:39:24] <dstufft> https://github.com/python/psf-fastly/blob/master/vcl/pypi.vcl#L45-L50

[17:39:29] <dstufft> a POST request will not get redirected

[17:39:51] <dstufft> primarily because the python stdlib doesn't handle that case very well

[17:40:21] <Ivo> haha

[17:41:05] <dstufft> but the backend servers don't speak plaintext HTTP at all, only the CDN edges

[17:41:18] <dstufft> and the CDN edges have that VCL

[17:41:21] <Ivo> dstufft: do you consider the "system python can't compile shit on xcode 5.1" an apple bug or something setuptools/pip can fix?

[17:41:47] <dstufft> Ivo: I consider it an apple bug, but I go back and forth on if we should work around it or not

[17:42:01] <dstufft> the next clang will make our workaround useless

[17:42:08] <Ivo> orly

[17:42:19] <Ivo> how so?

[17:42:36] <dstufft> the work around afaik is to tell clang to turn the error into a warning again

[17:42:38] <Ivo> don't tell me they're removing the don't-error-on-nonexistent-flags flag

[17:42:45] <dstufft> and they are removing that yes

[17:42:54] <Ivo> **** me

[17:43:26] <dstufft> the error says

[17:43:28] <dstufft> "clang: note: this will be a hard error (cannot be downgraded to a warning) in the future"

[17:43:46] <dstufft> https://github.com/pypa/pip/issues/1654

[17:44:06] <dstufft> I was more disagree-y on that day than I am today

[17:44:46] <Ivo> i really hate how you need a goddamn apple id to see anything in apple