Log file Viewer

[12:09:01] <dropdrive> On 2.6, am I right in thinking that if `a.b.c` is a namespace package (i.e. a/__init__ and a/b/__init__ is the boilerplate call to extend_path), it's okay to have another package `a.b` that has real code in a/b/__init__? I think this is because of the existence check for __init__.py in nspkg.pth, yes?

[17:27:17] <bebop-haiku> hello everyone. I have been updating my vagrant/puppet files to use ubuntu 14.04 and python 3.4 and noticed that using pip -e <virtualenv> no longer works. I am having some trouble trying to get pip to install into a virtualenv, as I cannot source the activate script. Does anyone have any advice on how to make pip work in a similar way to the -e option?

[17:27:58] <apollo13> bebop-haiku: can you provide more information than "no longer works"?

[17:28:12] <bebop-haiku> It no longer appears to be a command line option

[17:28:39] <bebop-haiku> pip3 -e virtualenvs/kala gives the error no such option: -e

[17:28:57] <apollo13> ah same here for pip2 it seems

[17:29:33] <bebop-haiku> hum, it used to work just fine to specify a virtualenv

[17:30:11] <apollo13> does pip install --root work?

[17:31:06] <bebop-haiku> I tried that but it pip said that the requiements were already satisfied in /usr/local/lib/python3.4/dist-packages, I guess I could try to uninstall all those packages and see if --root works

[17:31:25] <apollo13> ah

[17:32:39] <apollo13> bebop-haiku: and you can't just use the pip from the venv/bin folder?

[17:32:51] <apollo13> it should choose the correct python, no need to source activate

[17:33:29] <bebop-haiku> well it is being run from a script, I could try to set the working directory

[17:33:56] <DanielHolth> the correct thing to do is /path/to/virtualenv/bin/pip install x

[17:34:21] <apollo13> bebop-haiku: not the working dir, just call the correct pip executeable

[17:34:26] <bebop-haiku> oh ok

[17:37:35] <bebop-haiku> great that works

[17:37:38] <bebop-haiku> thanks for the help

[17:39:21] <dstufft> -e was removed a long time ago

[17:39:48] <dstufft> If you were using the pip from 12.04 LTS packages you were using a really old pip from before it was removed

[17:39:57] <dstufft> bebop-haiku: ^^

[17:40:23] <bebop-haiku> dstufft: thanks that explains it

[17:40:35] <bebop-haiku> I was using pip from 12.04 lts

[17:41:02] <dstufft> bebop-haiku: That was version 1.0, 14.04 has 1.5.4

[17:41:21] <dstufft> https://github.com/pypa/pip/blob/develop/CHANGES.txt you might want to read over this to see what has changed, especially the ones marked **BACKWARDS INCOMPATIBLE**

[17:41:36] <dstufft> ignore the 1.6.0.dev1 entry though

[17:41:39] <dstufft> that hasn't been released yet

[17:41:58] <dstufft> Probably a better link https://github.com/pypa/pip/blob/master/CHANGES.txt

[17:42:21] <bebop-haiku> thanks for the link

[19:07:55] <winsoff> What does PIP stand for?

[19:08:10] <agronholm> winsoff: pip installs packages

[19:08:15] <winsoff> Goddamnit.

[19:08:22] <winsoff> I should have seen that coming.

[19:08:25] <agronholm> :)

[19:08:45] <winsoff> Why are recursive acronyms so funny?

[19:16:05] <wsanchez> Can I ask pip not to write to ~/.pip?

[19:16:56] <dstufft> wsanchez: do you want it to write somewhere else, or just not write at all

[19:18:06] <dstufft> I think the answer to the first one is probably --log-file=some/other/file/path, I think the answer to the second one is Nope, please open a ticke

[19:20:59] <wsanchez> Our build system runs as root (Whoo!) sets up a sandbox to prevent writing to stuff outside of designated locations.

[19:21:14] <wsanchez> I'll try --log-file, thanks

[19:22:34] <wsanchez> Hrm I was using --log, which I guess isn't what I want

[19:28:25] <dstufft> wsanchez: So pip logging is super confusing and bad

[19:28:28] <dstufft> There are two logs

[19:28:37] <dstufft> --log is an appending log that is off by default

[19:28:54] <dstufft> and --log-file is a overwriting debuging log of the last invocation and is on by default

[19:31:05] <jezdez> wasn't there a plan to get rid of one of them?

[19:31:27] <jezdez> also, hi :)

[19:32:59] <dstufft> jezdez: heya :D

[19:33:11] <dstufft> jezdez: yes I think there was, I think qwcode was working on it, not sure what came of it

[19:35:21] <qwcode> jezdez, dstufft, I ended up at least documenting them (http://www.pip-installer.org/en/latest/reference/pip.html#logging) and surfacing the one option that was hidden

[19:35:59] <jezdez> we could rename --log-file to --error-log

[19:36:01] <jezdez> or something

[19:37:17] <qwcode> yea, that's a better name

[19:39:12] <dstufft> TBH I'm not sure we even need either of them, It seems like an appending log is easier implemented as pip install foo >> /path/to/logfile or pip instal foo | tee -a /path/to/logfile and the "error log" is better implemented as pip install -vvv foo > /path/to/logfile or pip install -vvv foo | tee /path/to/logfile

[19:39:55] <dstufft> (I get what the idea of the error log is, but I'm not sure anyone ever actually looks at ~/pip/pip.log to see the debug view of the last command rather than just run it again with -vvv)

[19:41:08] <dstufft> (also I like the idea of having less code and less options :D)

[19:43:47] <qwcode> yea, I admit I punted due to not wanting to stress over breakages and fallout with build systems using the current log options

[20:26:43] <wsanchez> Looks like pip invokes a python -c thingo and *that* wants to write to ~/.pip: python -c "import setuptools, tokenize;__file__='/...../CalendarServer/build/python-ldap/setup.py';exec(......)" install ......

[20:27:05] <wsanchez> I'm sorry for whoever had to write that.

[20:33:15] <qwcode> wsanchez, pip writes to it's log files using pip.log

[20:33:44] <qwcode> pip.log.Logger

[20:35:07] <qwcode> it does potentially write subprocess output it gets from setuptools

[21:28:39] <mugwump> I'm getting this error trying to use virtualenv:

[21:28:39] <mugwump> ImportError: No module named '_collections_abc'

[21:28:47] <mugwump> with python3.4

[21:29:53] <agronholm> how are you setting it up

[21:31:17] <mugwump> I first installed a system python3.4

[21:31:41] <mugwump> using the ubuntu trusty python 3.4 package, back-ported to saucy

[21:32:00] <mugwump> then setuptools and pip were installed from source using python3.4 setup.py install

[21:32:15] <mugwump> then I used pip3.4 install virtualenv

[21:33:06] <agronholm> it would have been easier to just run get-pip.py

[21:33:15] <agronholm> which will download and install both setuptools and pip

[21:34:39] <mugwump> oh, right I didn't know that

[21:34:51] <mugwump> I just realized that I didn't 'setup.py clean' before I ran install

[21:35:07] <mugwump> so, I started from scratch and that seems to have fixed it

[21:35:10] <agronholm> I've never done that

[21:35:31] <mugwump> sure. I'd last used those source trees for installing those utils in a pypy installation on this host