Log file Viewer

[10:34:41] <marco_sm> hi, does anyone know if it is possible to install a package with pip from a git repository without the -e option (not in editable mode)?

[10:35:35] <marco_sm> if I put this in my requirements.txt file:

[10:35:37] <marco_sm> -e git+git@my_git_host:my/package.git@0.5.0#egg=my_package

[10:35:59] <marco_sm> it install the package under the src folder of the witrual env

[10:36:22] <marco_sm> but if I remove the -e option I got an error

[11:09:54] <ionelmc> marco_sm: what error?

[11:12:54] <marco_sm> let me run quikly the install and I paste the error

[11:15:03] <marco_sm> Invalid requirement: git+git@my_git_host:my/package.git@0.5.0#egg=my_package

[11:15:12] <marco_sm> It looks like a path. Does it exist ?

[11:15:40] <marco_sm> But the requirement is the sam that with the -e option is installed under src

[11:15:58] <marco_sm> [the same]

[13:58:54] <znc_user_> hi there. i'm experiencing a weird error using pip inside of docker which can be seen in gist of comment here: https://github.com/docker/docker/issues/12327#issuecomment-184659491

[13:59:31] <znc_user_> rmtree_errorhandler, no such file or directory

[14:00:23] <znc_user_> my environment is docker 1.9.1, overlayfs storage, ubuntu 16.04 container, with 'apt-get install python pip'

[14:00:55] <znc_user_> it's been suggested i report this error to you guys, in case you might feel inclined to look into the matter

[14:01:58] <xafer> Hello, if you are referring to https://github.com/pypa/pip/pull/3425 it was rejected

[14:02:55] <xafer> The issue should be fixed in overlayfs :)

[14:04:27] <znc_user_> that's a shame

[14:04:46] <znc_user_> given how small the code change is

[14:04:58] <znc_user_> but yeah... that seems to be it

[14:07:27] <znc_user_> so either be custom - patching pip, or else upgrade overlayfs / kernel

[14:13:56] <znc_user_> afaikt theres no patch for overlayfs yet

[14:26:28] <znc_user_> xafer: well aparrently "the maintainer for overlayfs in the kernel is not responding, so we cannot get the patch merged upstream"

[14:27:17] <znc_user_> so any flexibility / understanding appreciated. since fixing the overlayfs bug could drag on for a while

[14:27:27] <znc_user_> (not that we want it to)

[14:28:43] <xafer> Well you can always use FragLegs branch if you need it, but it's unlikely to be merged in pip develop.

[14:29:57] <xafer> pip install git+https://github.com/FragLegs/pip@patch-for-issue-2953

[14:30:23] <xafer> (But ideally you'd want to fork his fork to be sure what you are installing)

[14:30:54] <znc_user_> yeah thanks xafer... was looking for some instruction like that how to install his branch

[14:31:26] <znc_user_> can try it now

[14:31:33] <xafer> And if you dont want to git clone each time you install, you'd better release some wheel for his version and host it somewhere

[14:32:02] <znc_user_> xafer: it's fine for this container, as git is already installed in it. and docker layers = reusable

[14:32:33] <znc_user_> so it should be cached the layer

[14:32:49] <xafer> yup except when the filesystem has some issue I guess ;)

[14:38:33] <znc_user_> haha. maybe its some miscommunication with the maintainer for overlayfs

[14:38:45] <znc_user_> like he didn't get the message or something

[14:39:18] <znc_user_> just waiting / rebuilding that pip workaround now

[15:21:27] <znc_user_> so i tried doing this:

[15:21:30] <znc_user_> RUN apt-get update && apt-get install -y python-dev python-pip && pip install --upgrade pip \ && pip install git+https://github.com/FragLegs/pip@patch-for-issue-2953

[15:21:48] <znc_user_> however unfortunately it cause error / bug in other places

[15:22:02] <znc_user_> so can't use it

[15:22:19] <znc_user_> (that is on unbuntu 16.04)

[15:25:01] <znc_user_> error at bottom of log ---> https://gist.github.com/dreamcat4/7d0558541c491ac4bf61

[16:18:28] <wh3ko19> So I've been trying to build numpy statically, so I can distribute it as an egg to a cluster with no dependencies.

[16:19:12] <wh3ko19> I got it built OK with a static libatlas, but now I can't figure out how to get it to statically link libc.

[16:19:56] <wh3ko19> I tried just adding libc.a as an extra link arg.

[16:20:05] <wh3ko19> But that's not working.

[16:30:57] <dstufft> assuming glibc, you can't really statically link it

[16:31:09] <dstufft> it really really doe snot want to do that, and it breaks in weird ways

[16:37:04] <wh3ko19> That's unfortunate.

[16:42:06] <dstufft> wh3ko19: it's not all bad though, because glibc is really good at backwards compat

[16:42:25] <dstufft> wh3ko19: so just compile an an ancient box using a glibc older than the box you're trying to run it on and it all generally works

[16:44:40] <wh3ko19> dstufft: Cool.

[16:44:42] <wh3ko19> Thanks.

[23:08:48] <njs> hmm, wh3ko19 is gone, so I can't just point them at the manylinux numpy wheels...

[23:08:54] <njs> oh well