pmxbot IRC Log Viewer

[17:49:13] <tos9> How / why is pip lying to me

[17:49:28] <tos9> It claims to be downloading a tar from a URL, then complains that files are missing from the package

[17:49:34] <tos9> But the files are there when I download the tar

[17:49:50] <tos9> And in fact are not there in the tmp directory that pip leaves behind.

[17:50:30] <dwi> out of curiosity, what package?

[17:50:38] <tos9> Coming up

[17:50:41] <dstufft> can you be more specific as to package and output

[17:51:27] <tos9> http://bpaste.net/show/dbt06cL5gttmnpHjy9qd/

[17:53:21] <tos9> https://github.com/mitsuhiko/markupsafe/blob/master/setup.py doesn't appear to be being nefarious.

[17:54:21] <dstufft> tos9: works for me

[17:54:35] <dstufft> i wonder if "or not a regular file" is a clue in the error message

[17:54:50] <dstufft> maybe perms are messed up or something?

[17:55:00] <dstufft> what version of pip are you using.

[17:55:26] <tos9> pip 1.3.1 from /usr/lib/python2.6/site-packages/pip-1.3.1-py2.6.egg (python 2.6)

[17:55:32] <tos9> setuptools 1.1.5

[17:55:36] <dstufft> oh

[17:55:39] <dstufft> old

[17:55:41] <dstufft> hmm

[17:55:46] <dstufft> let me try w/ those versions

[17:57:01] <tos9> I mean, it's not lying right? /tmp/pip-build-deploy/markupsafe/markupsafe is empty.

[17:57:08] <tos9> I have no idea how / why it is though.

[17:58:29] <dstufft> hum

[17:58:35] <dstufft> version 0.23

[17:58:41] <dstufft> but that setup.py says .22

[18:00:01] <tos9> A ha.

[18:00:34] <tos9> Well it fails in the same way for markupsafe==0.22

[18:02:08] <tos9> And now I run away for 20 minutes.

[18:36:39] <tos9> OK, sort of back -- is there something obvious I'm missing here, it seems like something is weird about the markupsafe uploads (cc mitsuhiko) but still pip seems to be deleting files

[18:36:47] <tos9> or otherwise getting different ones than I get when I download its tar

[18:37:03] <mitsuhiko> what's broken?

[18:37:36] <tos9> I'm not sure yet, but recent installs of flask started failing for us -- so far the only thing that seems amiss is that you tagged a release 0.23 and it's uplaoded as such to PyPI seemingly, but setup.py declares it to be 0.22

[18:37:42] <tos9> the paste of the install is:

[18:37:46] <tos9> http://bpaste.net/show/dbt06cL5gttmnpHjy9qd/

[18:38:13] <dstufft> tos9: i'm not sure wtf is going on

[18:38:19] <dstufft> I can't repo

[18:38:20] <tos9> dstufft: can you repro?

[18:38:21] <tos9> :(

[18:38:40] <mitsuhiko> tos9: are you using devpi?

[18:38:41] <tos9> guess it's time to pudb setuptools again yayayaya

[18:38:51] <tos9> mitsuhiko: No, not yet

[18:40:09] <mitsuhiko> tos9: jftr. the version on pypi of markupsafe says 0.23 in setup.py

[18:40:25] <mitsuhiko> this file: https://pypi.python.org/packages/source/M/MarkupSafe/MarkupSafe-0.23.tar.gz#md5=f5ab3deee4c37cd6a922fb81e730da6e

[18:40:54] <tos9> ah I see, ok well that's not it then I guess. I mean I do see a totally fine looking package when I download that tar

[18:58:34] <tos9> dstufft: OK, I guess I bet I know what the issue is

[18:58:44] <tos9> Or how to attempt to reproduce, but I don't feel like doing that right now

[18:58:52] <dwi> tos9: what distro are you running?

[18:58:54] <dstufft> whats that?

[18:59:18] <tos9> Basically blowing away /tmp/pip-build-deploy fixed it, so something untarred some stuff, put it in the build directory, but then failed, and then probably pip just reuses what it finds in there

[18:59:22] <tos9> which isn't in a state that's installable

[18:59:34] <tos9> dwi: CentOS 6.3

[18:59:54] <tos9> So successive installs fail and probably didn't actually do any networking to download a correct version of the package

[19:00:22] <dstufft> oh

[19:00:23] <dstufft> ys

[19:00:28] <dstufft> it did back in 1.3

[19:00:35] <dstufft> upgrade to a newer version

[19:00:37] <tos9> Heh, well, hooray, glad that's fixed.

[19:00:40] <tos9> dstufft: CentOS bro

[19:00:42] <tos9> Gimme like 10 years.

[19:01:00] <dstufft> just download this one wierd python script to install your pip

[19:01:06] <dstufft> it'll be fiiiine

[19:01:10] <tos9> :)

[19:01:39] <dstufft> in 10 years we'll probably be on pip version 5 and centos will finally get pip 1.5

[19:01:45] <tos9> (We do that, but only on jenkins builds -- but that comes with its own funness with varying wget and curl versions :P)

[19:02:13] <dstufft> yea ancient versions of wget don't do SAN lol

[19:02:23] <tos9> Yeah, which is apparently the version in 6.3 repos

[19:02:28] <tos9> So hooray software :)

[19:02:51] <dwi> tos9: 6.4 is EOL too. :)

[19:02:56] <dwi> err 6.3

[19:03:06] <dwi> actually 6.4 is too

[19:03:41] <tos9> yeah, I'm sure we'll move to 7 at some point, but last time we tried performance tanked for us.

[19:03:45] <tos9> So we need to figure out why.

[19:03:58] <dwi> well CentOS only supports the latest point release

[19:04:00] <dwi> so 6.5

[19:04:45] <dstufft> pypa uses 6.5

[19:04:47] <dstufft> it's ok

[19:05:04] <dstufft> only because EWDurbin makes us rpms whenever i get annoyed at old releases of things tho :D

[19:08:48] <tos9> hahah

[19:14:20] <dwi> thankfully now RH is building newer RPMs(as a result CentOS can get them too), although I've not actually used those specifically.

[19:14:49] <dwi> still not as recent as the latest though.

[19:14:58] <dstufft> epel is ok

[19:15:07] <dstufft> too bad if it's packaged in the release you're still boned

[19:16:22] <dwi> The Software Collections Library has the newer stuff

[19:36:14] <EWDurbin> SCL is really difficult to use for runnning servcies IMO

[19:36:35] <EWDurbin> there's a boatload of PATH/ENV crap muddled on top of it

[19:37:04] <EWDurbin> an altinstall python is a hell of a lot easier to work with

[22:33:55] <sontek_> /opt/webapp/anonweb/bin/pip install -i http://packages/index --editable /opt/src/anonweb/ returns this: /opt/src/anonweb/ should either be a path to a local project or a VCS url beginning with svn+, git+, hg+, or bzr+

[22:34:04] <sontek_> pretty sure -e usually works with a local path as well

[22:34:41] <sontek_> what would cause that?

[22:35:38] <sontek_> oh, hah, nvm. What it means is "that path doesn't exist"

[23:34:04] <agronholm> if I install a wheel, is pip supposed to uninstall the old version of the distribution?

[23:48:00] <dropdrive> Hi, should I expect setuptools "development mode" to work for namespace packages? Given my understanding of .pth and .egg-link, it seems like this is simply not supported. Is this correct?

[23:52:53] <dstufft> agronholm: yes

[23:53:07] <agronholm> dstufft: it's not doing that

[23:53:12] <agronholm> it just leaves the old versions there

[23:53:22] <dstufft> hmm

[23:53:28] <dstufft> how was the old version installed

[23:53:37] <agronholm> pip install <path_to_wheel>

[23:53:54] <dropdrive> agronholm: Did the two wheels have different versions? Because I've seen that happen when I installed two 0.0.0 wheels.

[23:54:01] <agronholm> yes

[23:54:12] <agronholm> .pre3, .pre4, .pre5

[23:55:16] <agronholm> dropdrive: but if they had the same version, it would just overwrite the stuff, wouldn't it

[23:55:30] <agronholm> well except for the console scripts maybe

[23:56:37] <dstufft> agronholm: was the new version installed with <path_to_wheel> ?

[23:56:43] <agronholm> dstufft: yes

[23:57:17] <dstufft> might be a bug with that

[23:57:46] <agronholm> I'll try to reproduce this trivially

[23:58:40] <dropdrive> dstufft: Any chance you know about namespace packages and dev mode (in Py2)?

Log file Viewer

Help | Karma | Search:

#pypa logs for Tuesday the 20th of May, 2014