pmxbot IRC Log Viewer

[09:44:08] <calston> this pip6.0.7 keeps exploding

[09:44:10] <calston> https://gist.github.com/calston/9aefc7308e5cf2382566

[10:30:56] <mgedmin> calston: you may want to file a bug at https://github.com/pypa/pip/issues

[10:31:23] <mgedmin> curiously, pip 6.0.7 works here

[10:32:02] <mgedmin> my /home/mg/.venv/local/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/__init__.py doesn't have any imports from ..exceptions

[10:32:24] <mgedmin> oops I looked at the wrong file

[10:32:51] <mgedmin> my /home/mg/.venv/local/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/exceptions.py defines a ProtocolError

[10:33:28] <mgedmin> maybe don't be in a rush to file the bug :)

[11:04:10] <calston> mine does not

[11:06:11] <mgedmin> hey, there's no 6.0.7 tag on github

[11:07:04] <mgedmin> master has this: https://github.com/pypa/pip/blob/develop/pip/_vendor/requests/packages/urllib3/exceptions.py#L51

[11:07:11] <mgedmin> last changed in dec 2014

[11:07:19] <mgedmin> how did you install pip 6.0.7?

[11:07:24] <calston> with pip

[11:07:53] <calston> pip install --upgrade pip

[11:08:04] <mgedmin> that should work

[11:08:28] <mgedmin> do you want to compare /home/colin/python/local/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/retry.py with the version on github that I just linked?

[11:08:41] <mgedmin> actually better compare .../urllib3/exceptions.py :)

[11:11:23] <calston> starts out the same, something somehow overwrites it

[11:12:44] <mgedmin> pastebin the diff?

[11:14:14] <calston> trying to find in the nightmareish hell of dependencies which one does it

[11:14:51] <mgedmin> I don't think that's possible

[11:15:16] <mgedmin> I'd hope package X shouldn't be able to overwrite files belonging to package Y

[11:15:28] <mgedmin> pip installs manifests with checksums, you may want to compare those

[11:15:53] <mgedmin> personally I'd be inclined to suspect filesystem corruption (maybe due to flaky hardware)

[11:39:07] <ionelmc> maybe upgrade failed in the middle, leaving an incomplete upgrade?

[12:09:23] <calston> hmm, seems it's actually virtualenv

[12:09:37] <mgedmin> ooh, interesting

[12:10:27] <calston> (or rather peoples bad use of it)

[12:10:59] <calston> if you make a virtualenv, upgrade pip, try to make the same virtualenv again it overwrites a bit of pip

[12:11:18] <calston> instead of going "there's already a virtualenv here"

[12:12:25] <mgedmin> brilliant

[12:12:54] <mgedmin> file a virtualenv bug?

[12:15:34] <calston> 1.11.4

[12:15:46] <calston> isn't that already from medieval times?

[12:16:18] <mgedmin> latest is 12.0.6

[12:17:21] <calston> wow

[12:17:54] <calston> how do the packages in new Ubuntu "LTS" already end up a decade old by the time its released

[12:19:04] <mgedmin> was that a rhetorical question?

[12:20:06] <Wooble> calston: they're "stable" because their bits have had 10 years to settle! :)

[12:24:20] <calston> mgedmin: yes :P

[12:34:31] <dstufft> calston: note that 12.x changed the version number scheme and under the old scheme would have been 1.12

[12:34:41] <dstufft> so 1.11 is only one version older than 12.0

[12:38:08] <calston> ah right

[12:38:31] <calston> still, I hate my job

[12:38:40] <calston> but thanks for the help

[14:09:42] <mitsuhiko> dstufft: i'm not ruling out that i do somethign very wrong

[14:09:51] <mitsuhiko> but the version reported from setup.py is what you mentioned basically

[14:10:03] <dstufft> mitsuhiko: what versions of pip and setuptools

[14:10:11] <mitsuhiko> dstufft: latest

[14:10:40] <dstufft> What are you doing, is this ``pip install`` from an index, from a local file, etc?

[14:10:45] <mitsuhiko> i am doing this:

[14:10:45] <mitsuhiko> pip install --pre --no-index --find-links=. fireline

[14:10:58] <mitsuhiko> pip names the file this:

[14:10:58] <mitsuhiko> fireline-0.13.dev_8085d9e3df9a-cp27-none-linux_x86_64.whl

[14:11:05] <mitsuhiko> as of why, i do not know

[14:11:12] <mitsuhiko> but pip then reads it as dev-whatever

[14:11:27] <mitsuhiko> the version according to setup.py --version however is 0.13.dev+8085d9e3df9a

[14:12:48] <dstufft> I wonder if wheel is mangling the version

[14:14:36] <dstufft> mitsuhiko: are you using the latest setuptools when creating the wheel file?

[14:14:43] <mitsuhiko> dstufft: yes

[14:15:38] <dstufft> hmm

[14:15:57] <dstufft> the problem is the wheel is named fireline-0.13.dev_8085d9e3df9a-cp27-none-linux_x86_64.whl instead of fireline-0.13.dev+8085d9e3df9a-cp27-none-linux_x86_64.whl

[14:16:08] <dstufft> I'm not sure why that is though

[14:16:18] <dstufft> the wheel code base doesn't seem to be doing that

[14:16:35] <dstufft> and when I test locally I get dstufft_testpkg2-13.13.13+asdasd-py2.py3-none-any.whl just fine

[14:26:12] <mitsuhiko> i will investigate

[14:42:51] <mitsuhiko> dstufft: how did you create the file with a + in there?

[14:43:31] <dstufft> mitsuhiko: python setup.py bdist_wheel with a setup.py like -> https://bpaste.net/show/ea95b69be71f

[14:44:17] <mitsuhiko> dstufft: that's what i do

[14:44:19] <mitsuhiko> i get an underscore

[14:45:31] <dstufft> setuptools (12.0.5) and wheel (0.24.0) ?

[14:46:49] <xafer> FWIW, I just tested and got dstufft_testpkg2-13.13.13+asdasd-py2-none-any.whl also

[14:49:08] <mitsuhiko> dstufft: from what i can tell yes, but something must be off

[14:49:14] <mitsuhiko> i tried on a new virtualenv and there i get a +

[14:49:57] <dstufft> ok

Log file Viewer

Help | Karma | Search:

#pypa logs for Wednesday the 4th of February, 2015