Log file Viewer

[04:31:57] <tdsmith> any opinion why https://pypi.python.org/pypi/vobject/json gives an empty list for "urls"?

[04:32:40] <dstufft> ummm

[04:32:56] <dstufft> tdsmith: btw, pip 7 released

[04:33:00] <dstufft> like, 30 minutes aogo

[04:33:33] <tdsmith> i think it's related to confusion about whether 0.8.1 or 0.8.1c is the newest version. 0.8.1 doesn't have any downloads posted. release_url is "http://pypi.python.org/pypi/vobject/0.8.1" -- visiting that in the browser says that 0.8.1c is the newest version, though

[04:33:37] <tdsmith> nice, hot out the oven

[04:34:43] <dstufft> tdsmith: you may or may not want to wait to update things in homebrew- it's got a fairly major change in behavior and it wouldn't surprise me if things shake out as people start using it

[04:35:24] <tdsmith> i thought i might give it a few days :) does this do wheel-building now?

[04:35:45] <tdsmith> ooh, it does

[04:35:50] <dstufft> tdsmith: yes it does

[04:35:52] <dstufft> that's the change

[04:38:28] <dstufft> tdsmith: so yea, I'm pretty sure that the problem here is that PyPI is seeing 0.8.1c as the latest version, however that version is hidden which means it won't show up in the UI as a latest version, but it _will_ show up in APIs as the latest version

[04:40:52] <tdsmith> weirdly, the behavior seems like the inverse of that: https://pypi.python.org/pypi/vobject shows downloads for 0.8.1c, but https://pypi.python.org/pypi/vobject/json has an empty url section

[04:42:35] <dstufft> er, rather I mean it sees 0.8.1 as the latest version, 0.8.1c looks like a release candidate of 0.8.1

[04:42:38] <dstufft> but 0.8.1c is hidden

[04:42:53] <dstufft> 0.8.1 is hidden*

[04:43:18] <dstufft> so the JSON shows 0.8.1, since it thinks that's the latest and it ignores the hidden specifier

[04:43:28] <tdsmith> gotcha

[04:43:36] <tdsmith> thanks for explaining!

[04:43:36] <dstufft> and the UI shows 0.8.1c since 0.8.1 is hidden and 0.8.1 is not

[04:43:46] <dstufft> too damn tired for version numbers

[04:43:48] <dstufft> :D

[04:44:15] <tdsmith> a shame pep 440 wasn't a thing in 2009

[04:45:15] <dstufft> heh

[04:45:15] <dstufft> yes

[04:45:55] <dstufft> PEP 440 was like, 5 years of effort if you count PEP 386, which PEP 440 was "let's take that thing, actually care about backwards compat to a bigger degree, especially with relation to pkg_resoruces, and then let's get the damn thing implemented"

[04:54:56] <tdsmith> will pip bundle wheel someday?

[04:55:33] <tdsmith> i'm wondering if homebrew python should come with wheel

[04:56:39] <dstufft> tdsmith: No, the goal for wheel (and setuptools) is that pip will learn how to install build dependencies, including those two, for projects and install them into a temporary location, build the wheel, then cache the wheel and install from that in the future

[04:57:23] <dstufft> for the time being we've just depended on having wheel and setuptools already installed to install from a sdist (though if you don't have wheel, everything still works, you just don't get wheel building) until that's ready

[04:58:02] <tdsmith> roger

[04:58:19] <tdsmith> so "yes" probably :)

[04:58:41] <tdsmith> to my wondering

[04:59:14] <dstufft> tdsmith: yes in the short term it should probably come with wheel

[04:59:32] <tdsmith> i guess if pip caches the wheel wheel it doesn't make much difference

[04:59:35] <tdsmith> in the future

[04:59:50] <tdsmith> this is neat

[05:00:16] <dstufft> ``pip install lxml`` in under a second is pretty great

[05:00:58] <tdsmith> seems like a big win for the scientific stack in virtualenvs too

[05:02:45] <dstufft> hopefully yea

[05:03:03] <dstufft> I'm sure it's going to break things

[05:03:17] <dstufft> a lot of things wern't expecting to be wheels are suddenly going to be

[05:03:45] <dstufft> but I don't have a better solution than to just do it and let people disable on a per package basis to start pushing people towards fixing their stuff

[05:09:55] <tdsmith> where do the cached wheels live on os x? i'm envisioning problems when a cached wheel is linked against a dylib that disappears (because e.g. the C library was upgraded and the dylib version changed because the upgrade broke the ABI) and it would be good to know what to blow away

[05:11:38] <dstufft> tdsmith: cache dir, ~/Library/Cache/pip/wheels/<hashed directory structure>/whatever.whl

[05:12:05] <tdsmith> groovy

[05:12:25] <dstufft> easiest thing to do is jsut rm -rf ~/Library/Cache/pip/wheels, but that loses all your cached wheels, you could use find to figure out what the hashed directory is and then delete just that file

[10:37:59] <jang> Hey everyone. I'm having trouble with a "pip install py" - using pip 7.0.0. The problem appears to be that https://pypi.python.org/pypi/py/ contains a bunch of links to specific versions. None of the links on that page are actually usable by pip as far as it's concerned: I see -

[10:38:03] <jang> Skipping link https://pypi.python.org/pypi/py/1.4.27 (from https://pypi.python.org/pypi/py/); unsupported archive format: .27

[10:39:42] <jang> can anyone suggest how I might install that?

[10:39:56] <jang> (this breaks installations of things like pytest, too.

[10:40:52] <tomprince> I can't reproduce.

[10:46:18] <jang> hrm. What does https://pypi.python.org/pypi/py/ look like to you? At the moment I'm having to work around this with a requrements.txt entry that has a line in it reading:

[10:46:18] <jang> https://pypi.python.org/packages/2.7/p/py/py-1.4.27-py2.py3-none-any.whl#md5=5cd706680117b45761f511d405c292fa

[10:47:15] <tomprince> pip shouldn't be looking at https://pypi.python.org/pypi/py/ anyway.

[10:47:38] <tomprince> What is that output of 'pip install -v py' ?

[10:49:00] <tomprince> For me, it is looking at https://pypi.python.org/simple/py/

[10:49:37] <jang> ah-ha.

[10:50:37] <jang> that's the problem: for some reason (pilot error) there's a extra-index-url = https://pypi.python.org/pypi in pip.conf, not .../simple

[10:51:17] <jang> sorted. great, thanks

[13:55:34] <fladd> hi there, quick question. When I uninstall a Python package, wich was installed with a wheel that included extra data (that goes into dist.prefix apparently). Will PIP also remove this extra data?

[13:56:16] <fladd> If not, is there a way to hook into the wheel install mechanism, to uninstall it manually before a new version (with potentially new extra data) of the same package is installed?

[13:57:08] <apollo13> fladd: wheel install mechanism is basically just an unzip

[13:57:16] <apollo13> and everything which is installed should get uninstalled

[13:57:29] <apollo13> just check pip uninstall if it includes your extra data

[13:57:46] <fladd> how do I check that?

[13:57:58] <apollo13> it will list you the files it will be removing

[13:58:14] <fladd> is there a switch to only check, but not actually remove?

[13:58:26] <apollo13> yes

[13:58:35] <apollo13> it will ask you if you actually want to continue…

[14:02:07] <fladd> apollo13, it is included, wonderful!

[14:02:22] <fladd> What will PIP do with the extra data, when updating a package?

[14:02:28] <fladd> Will it first uninstall the old data?

[14:04:06] <apollo13> just create a venv and try ;)

[14:05:25] <fladd> apollo13, yeah, but then i need to create a new version of my package first. I was hoping someone just knows this by hard :-)

[14:05:54] <dstufft> on upgrade pip does an uninstall of the old version and an install of the new version

[14:06:08] <dstufft> it's basically pip uninstall -y <whatever> && pip install <whatever>

[14:06:18] <fladd> wonderful, thanks a lot!

[15:01:20] <mathstuf> hi, whats the easiest way to upgrade openssl on windows for python26 so that pip can actually work?

[15:01:25] <mathstuf> or how to make it not do SSL

[15:02:27] <mathstuf> seems that it autoredirects to ssl, so that isnt an option either

[15:02:44] <dstufft> mathstuf: upgrade to Python 2.7?

[15:02:51] <dstufft> mathstuf: well

[15:03:05] <dstufft> mathstuf: you might be able to install pyopenssl ndg-httpsclient and pyasn1

[15:03:12] <dstufft> that will probably let you get around that

[15:03:15] <dstufft> and their deps

[15:03:33] <mathstuf> thatd be nice, but id like to test 2.6 and i need to install buildbot for it :)

[15:03:45] <mathstuf> though i suppose buildbot itself is not connected with what is being tested

[15:04:38] <mathstuf> could the docs be updated to mention that extra steps are required for 2.6 on windows?

[15:51:44] <apollo13> dstufft: /home/fapo/.local/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.

[15:51:46] <apollo13> mhm?

[15:51:54] <apollo13> on a debian python?

[16:46:11] <dstufft> apollo13: it doesn't have SSLContext

[16:46:24] <apollo13> dstufft: when was that introduced?

[16:47:13] <apollo13> ah 3.2?!

[16:48:09] <apollo13> oh pyopenssl would work too, nevermind

[16:54:50] <dstufft> apollo13: 3.2 and 2.7.9