Log file Viewer

[00:06:40] <tomprince> buck11: https://github.com/pypa/pip/pull/2196 but unfortunately, that broke some packages.

[00:07:02] <buck11> tomprince: i meant as a user

[00:07:04] <tomprince> The solution is to run 'sdist' first.

[00:07:26] <buck11> manfest ignore maybe

[00:07:31] <buck11> manifest*

[00:08:30] <tomprince> Replace 'pip install .' with 'python setup.py sdist && pip install dist/<package>'

[00:09:21] <buck11> that was the proposed patch?

[00:09:39] <buck11> oh not really

[00:11:54] <buck11> it seems like dstufft is seeking a patch to do that tho

[10:02:11] <Dulcin> Hi, if I have a virtualenv in an /opt/ directory I have to sudo pip install, but then it looks at the global python packages, instead of the ones in the virtualenv. How can I solve this?

[10:30:51] <ionelmc> Dulcin: what does sudo have to do with the virtualenv ?!

[10:39:07] <Dulcin> well to my understanding if I 'sudo pip install' instead of 'pip install' it checks the global python packages, instead of the one in my virtualenv even though it's activated

[10:39:31] <Dulcin> but I have to sudo, because I'm in the /opt/ directory

[10:40:07] <Dulcin> ionelmc: am I wrong in that reasoning?

[10:40:25] <Dulcin> but I think I solved it by adding the --ignore-installed flag

[10:41:03] <ionelmc> Dulcin: virtualenv doesn't allow lookup in the global site-packages for some time now

[10:41:05] <Dulcin> no I did not solve it :(

[10:41:18] <ionelmc> you can activate that option with --system-site-packages

[10:41:54] <ionelmc> Dulcin: can you describe the problem with some examples?

[10:43:47] <Dulcin> Ok, so I activated my (new) virtualenv, I tell it to pip to install with 'pip install' it tells me permission denied (because it's in /opt/), if I run it as 'sudo pip install' it tells me the package requirements area lready sasisfied, even though my bin/lib folders are empty

[10:44:38] <Dulcin> As far as I can tell it tells me its sasisfied because when I sudo pip, it is not looking at the local site packages, but takes my global python installation

[10:53:00] <Dulcin> a simple way would be to chmod the virtualenv, but I'm hoping there's a solution within pip itself as well

[11:08:40] <s1341> Dulcin: i don't think that pip can do what you want.

[11:09:04] <s1341> you will need to chmod the dir

[13:06:40] <dstufft> Dulcin: sudo /opt/path/to/venv/bin/pip install

[14:03:42] <Dulcin> dstufft: cheers!

[14:59:17] <__apr__> hi all

[14:59:43] <__apr__> I think I've found a bug

[15:00:21] <__apr__> when I install scapy-real==2.2.0-dev using pip 6.0.3, it works well, but then a pip freeze yields 2.2.0-dev0 as the installed version

[15:00:27] <__apr__> why is pip appending that 0 ?

[18:20:53] <dstufft> __apr__: PEP 440 normalization rules

[18:21:26] <__apr__> dstufft, thanks, xafer helped me figure it out

[22:52:23] <_habnabit> so it looks like either pip or setuptools changed and now `jedi>=0.8.0` doesn't match the package `jedi-0.8.1-final0`

[22:52:41] <_habnabit> is there anything i can do before jedi fixes this problem and uploads their own package?

[22:52:54] <_habnabit> i suppose pinning an older version of pip or setuptools would work

[22:54:02] <dstufft> _habnabit: it's the -final0 that's causing it

[22:54:09] <_habnabit> yeah i know

[22:54:41] <_habnabit> but until they upload a new version i'm screwed afaict

[22:54:45] <dstufft> I think you can add pip install jedi==0.8.1-final0 or maybe === while you do the rest of the install command

[22:55:01] <_habnabit> it's not my package that specifies `jedi>=0.8.0`; it's wdb.server

[22:55:41] <dstufft> _habnabit: right, but I think (and my memory may be faulty), that you can do ``pip install wdb.server jedi==(=)0.8.1-final0

[22:55:56] <_habnabit> whoa

[22:56:00] <_habnabit> what does the (=) do

[22:56:33] <dstufft> nothing, I just mean it's either == or ===, I'm not sure if == will work or not

[22:56:48] <_habnabit> oh okay

[22:56:54] <_habnabit> so what does === do

[22:57:31] <dstufft> === is the PEP 440 arbitary specifier, meaning "we ain't gonna try to parse the crap you specify, just do case insensitive string comparison against it"

[22:58:05] <_habnabit> haha

[22:59:09] <dstufft> basically the escape hatch

[22:59:31] <dstufft> however the way we implemented PEP 440, ==<something that can't be parsed as PEP 440> will fall back to using the previous rules

[22:59:43] <dstufft> so I think the outcome will be roughly the same