Log file Viewer

[08:38:24] <xafer> Seems like pip tests in python2.7 are either timeouting or getting stucked again :-/ https://travis-ci.org/pypa/pip/pull_requests

[11:46:25] <dstufft> pf_moore: ping

[12:01:49] <rchekaluk> Downloading distribute_setup.py times out, has there been some recent DNS change?

[12:02:07] <rchekaluk> $ wget http://python-distribute.org/distribute_setup.py

[12:02:07] <rchekaluk> --2014-09-16 11:29:24-- http://python-distribute.org/distribute_setup.py

[12:02:07] <rchekaluk> Resolving python-distribute.org... 88.191.140.69

[12:02:07] <rchekaluk> Connecting to python-distribute.org|88.191.140.69|:80... failed: Connection timed out.

[12:02:07] <rchekaluk> Retrying.

[12:04:52] <dstufft> rchekaluk: python-distribute.org is probably gone by now, it's not ana ctive project anymore

[12:10:32] <rchekaluk> dstufft, well it was there only a couple days ago

[12:11:51] <dstufft> I'm not sure who contorls it tbh

[12:11:53] <rchekaluk> dstufft, In order to install a legacy app, do you know an alternative wget URL for distribute_setup.py?

[12:11:55] <dstufft> it might be Tarek still

[12:12:05] <dstufft> rchekaluk: it doesn't work with setuptools?

[12:12:29] <rchekaluk> dstufft, Will probably try that, just was trying to not alter an existing provisioning script

[12:12:35] <dstufft> there might be one on bitbucket

[12:12:42] <dstufft> that's where distribute was developed

[12:13:08] <rchekaluk> dstufft, Thx for the response and info

[18:30:22] <pf_moore> dstufft: you pinged? (some time ago...)

[18:32:07] <dstufft> pf_moore: oh, I was going to ask if virtualenv and venv on Windows make bin dirs or Scripts dirs and if it's called python or python.exe inside them

[18:32:23] <pf_moore> scripts, and python.exe

[18:32:51] <pf_moore> there was talk of switching to bin, but it was decided that would break too many things...

[18:33:43] <dstufft> pf_moore: ok thanks

[18:33:50] <dstufft> I was expiring with something earlier

[18:33:53] <dstufft> experimenting

[18:33:54] <dstufft> o.O

[18:34:07] <pf_moore> :-)

[18:34:35] <pf_moore> is that the activate stuff you were discussing on the tracker?

[18:34:59] <dstufft> that's part of it yea

[18:35:00] <dstufft> https://github.com/dstufft/pvr

[18:35:12] <dstufft> pvr will use either venv or virtualenv depending on which one is available

[18:35:27] <dstufft> I was trying to make it so instead of activating, you just run commands inside the venv

[18:35:38] <dstufft> like pvr exec bash

[18:35:48] <dstufft> but It doesn't work so well to do that

[18:35:55] <dstufft> so idk if it makes sense or not

[18:36:41] <tomprince> I thought there was already a thing to just run commands in a virtualenv.

[18:37:14] <tomprince> https://warehouse.python.org/project/ve

[18:37:50] <pf_moore> tomprince: there's a few things around, all having varying degrees of success

[18:38:04] <tomprince> vex is actually what I was thinking of.

[18:38:53] <pf_moore> dstufft: yeah, really we're trying to do a user's shell environment management for them, and doing that without getting shell-specific is messy

[18:40:00] <pf_moore> Problem with "run a command inside a venv" is that it's easy to forget

[18:40:24] <pf_moore> "pip install numpy" followed by "oops, meant to do that in a venv, not in the system Python" :-(

[18:40:32] <pf_moore> happened to me far too many times

[18:41:00] <dstufft> yea

[18:41:19] <pf_moore> And on the other hand, starting a new shell, teaches you to be a bit too happy to type "exit".

[18:41:36] <pf_moore> Logged out of systems a few too many times to be happy with that one, as well ;-)

[18:42:23] <dstufft> heh

[18:42:39] <pf_moore> Basically it's a whole load of effort to cover up the fact that all we're doing is adding a directory to PATH

[18:42:56] <pf_moore> The rest is just someone's eye-candy preferences, elevated to standard status

[18:43:24] <pf_moore> If it wasn't so freaking useful, I'd say remove it :-)

[18:44:12] <dstufft> heh

[18:44:13] <dstufft> yea

[18:44:36] <dstufft> this thing makes it so you can prefix anything with pvr exec and it'll run inside the venv

[18:45:43] <pf_moore> tomprince: vex actually looks quite nice. I may give it a try

[18:46:04] <tomprince> dstufft: That is exactly what vex does.

[18:46:44] <pf_moore> there are Windows examples given, which makes me think it might work there as well, which is why it interests me

[18:49:58] <dstufft> tomprince: yea this is a PoC thing

[18:50:03] <dstufft> me messing around early this morning

[18:54:17] <pf_moore> Actually, I'd be much happier if the activate scripts were *all* reduced to a bare minimum, just setting the PATH. Let users set prompts themselves. I have no idea how to do that in a backward compatible (i.e., wouldn't make people scream blue murder) way, though.

[18:54:42] <pf_moore> I'll probably just stick to writing my own Powershell functions, and abandon activate altogether...

[18:57:30] <dstufft> I think the problem with not setting the prompt is otherwise it's confusing if you're in the env or not

[19:00:36] <pf_moore> yes, I agree, but people have custom prompts and the way we set it can conflict

[19:00:57] <pf_moore> At least we should have "activate --no-prompt" or something...

[19:02:26] <pf_moore> My powershell prompt detects an active venv and includes the name automatically (by checking if $env:VIRTUAL_ENV exists)

[19:02:44] <pf_moore> So I normally get the venv displayed twice...

[19:04:21] <dstufft> export VIRTUAL_ENV_DISABLE_PROMPT=1

[19:04:25] <dstufft> disables it

[19:04:42] <dstufft> my zsh prompt detects it and includes it automatically, so my rc files just set that env var

[19:30:37] <pf_moore> dstufft: doh...

[19:54:28] <pf_moore> dstufft - Windows does horrid things that will make you cry if you try to get pvr working there. See https://github.com/sashahart/vex/issues/20 for how it affects vex...

[19:56:28] <DanielHolth> so how do you tell powershell it's allowed to run .bat files?

[20:00:08] <pf_moore> DanielHolth: it does automatically by passing them to cmd - although that means any env variables set in the bat file are forgotten afterwards

[20:00:35] <pf_moore> So they work much more like Unix shell scripts under powershell (which is overall a good thing IMO)

[20:28:43] <DanielHolth> pf_moore my powershell had a permissions / security toggle set that disallowed them

[20:37:51] <dstufft> is powershell like the bash on windows

[20:37:55] <dstufft> I always roll with cmd.exe

[20:37:57] <dstufft> is that wrong

[20:39:03] <DanielHolth> powershell is more like fish

[20:42:17] <DanielHolth> powershell has tab completion and decent scripting and so on

[20:47:33] <dstufft> so it comes with a web ui? :D

[20:47:50] <dstufft> (I find it hilarous that the fish shell has a webui)

[20:50:57] <DanielHolth> dunno about the web stuff

[20:51:04] <pf_moore> powershell is a much more powerful shell than cmd, probably more powerful than bash (native access to the full .net stack)

[20:51:25] <DanielHolth> first thing you'll notice is a better terminal

[20:51:41] <pf_moore> but it has a very unusual model - pipelines pass objects, not text, for example

[20:51:50] <pf_moore> takes some getting used to but worth it

[20:52:23] <pf_moore> powershell is an engine, can have lots of front ends. Not heard of a web one, but it's certainly possible...

[20:53:04] <pf_moore> Ha - Windows Powershell Web Access - http://technet.microsoft.com/en-gb/library/hh831417.aspx