Log file Viewer

[10:19:00] <jezdez> r1chardj0n3s: ping

[10:27:05] <r1chardj0n3s> jezdez: yo :)

[10:27:15] <r1chardj0n3s> jezdez: are you here to merge my two PRs? :)

[10:27:30] <jezdez> huh?

[10:27:41] <r1chardj0n3s> jezdez: heh. I have two open PRs that I'd like merged pls ;)

[10:27:55] <jezdez> ah, well, tests don’t pass

[10:28:02] <r1chardj0n3s> jezdez: this other thing is my attempt to resurrect and get merged something akin to the old PR 1214

[10:28:23] <r1chardj0n3s> oh, sure they do. just ignore that thing over there ;) [sorry, I will look into why they failed]

[10:29:00] <jezdez> ough, pr 1965 is quite intrusive

[10:29:04] <r1chardj0n3s> jezdez: so the thing I want to store is a per-pip-installation datestamp of the last time that pip checked whether it was up to date

[10:29:30] <jezdez> and you want to add that feature to pip itself?

[10:29:38] <r1chardj0n3s> 1965 isn't really that bad ... it doesn't really reach that far does it? or am I missing something?

[10:29:42] <jezdez> then your tweets were *totally* misleading

[10:29:47] <r1chardj0n3s> I want pip to check whether it's up to date

[10:30:00] <jezdez> up-to-date according to PyPI?

[10:30:08] <r1chardj0n3s> and to do that it needs to store something per-virtualenv (and other env, now that I realise it)

[10:30:12] <r1chardj0n3s> yep

[10:30:33] <r1chardj0n3s> because people running out-of-date pip is a serious issue we're going to keep running into

[10:30:50] <r1chardj0n3s> we're running into it *now* and it'd be nice to prevent it in the future :)

[10:31:27] <r1chardj0n3s> it was always my intention to get an update check into pip in the same time that we got pip into Python 3 but that got lost along the way :(

[10:31:35] <jezdez> yeah, you need to talk to dstufft why he withdrew the PR

[10:31:39] <r1chardj0n3s> [because of the issues in PR 1214]

[10:31:41] <r1chardj0n3s> I have :)

[10:31:56] <jezdez> I’m +0 on this in general, but I’m going to veto adding any virtualenv specific code to pip

[10:31:59] <r1chardj0n3s> he didn't have the energy to address the issues raised in 1214 and I do

[10:32:12] <r1chardj0n3s> yep, and I think my new idea avoids that

[10:32:13] <jezdez> so I’d rather introduce the notion of a PWD/.pip.conf file that stored that data

[10:32:42] <jezdez> if you’re asked dstufft you should share what he said :)

[10:32:43] <r1chardj0n3s> I figure a file in ~/.pip/ that has timestamps per pip installation path

[10:32:56] <r1chardj0n3s> "didn't have the energy to address the issues raised in 1214" :)

[10:33:08] <jezdez> that’s not a reason, just an excuse

[10:33:40] <r1chardj0n3s> well, the pressure to get pip into 3.4 meant that there could always be leaking

[10:33:52] <jezdez> in your scenario, how would you encode the pip path into a file?

[10:34:02] <r1chardj0n3s> anyway, I gotta go be a dad for a while. I'll be back in about 30.

[10:34:04] <jezdez> just one big ~/.pip/timestamps.json?

[10:34:11] <r1chardj0n3s> something like that

[10:34:19] <jezdez> ok, works for me

[10:34:30] <r1chardj0n3s> bbl

[10:34:34] <jezdez> cool

[11:42:16] <moben> it seems wheel versions 0.22.0, 0.23.0 and 0.24.0 are not tagged in hg, was that an oversight?

[11:42:40] <dstufft> jezdez: yea what r1chardj0n3s said. I was trying to land that before 3.4, and I didn't have time to land both that, and ensurepip (ensurepip itself barely made it in as it was, it was actually a few day late and larry allowed it). I just didn't have enough time/energy to make it all happen in time

[11:43:32] <jezdez> moben: seems like it, yeah. mind open a ticket?

[11:44:27] <jezdez> dstufft: cool, makes sense. I think r1chardj0n3s’ plan makes sense to me, storing the timestamp locally in ~/.pip/timestamps.json or something

[11:44:38] <dstufft> yea

[11:44:47] <jezdez> I guess distro folks would be interested in disabling that check

[11:45:10] <dstufft> maybe, my oroginal PR had a flag to disable it

[11:45:15] <dstufft> they might patch it out

[11:57:32] <moben> jezdez: done

[11:57:46] <jezdez> dstufft: yeah

[11:57:51] <jezdez> moben: awesome, thank you!

[11:58:17] <dstufft> https://github.com/mitsuhiko/pipsi

[12:05:04] <jezdez> yeah, I saw

[12:06:33] <jezdez> I think it’s an interesting pattern, but it has its downsides as well

[12:07:02] <jezdez> it assumes that virtualenv’s are long lived for example

[12:07:19] <jezdez> so it doesn’t have a way to upgrade the venvs for example

[12:07:22] <jezdez> when python is updated

[21:35:46] <r1chardj0n3s> dstufft: pipsi didn't work for me on the first thing I tried: devpi

[21:36:05] <dstufft> r1chardj0n3s: never used it

[21:36:16] <dstufft> it just looked interesting

[21:37:39] <r1chardj0n3s> yeah, I thought it was neat - given that devpi ends up with its own venv anyway

[21:37:40] <wickman> i'm writing something similar to this called pexify, that takes an sdist and poops out pex files for each of its console_scripts that can be dumped into ~/local/bin

[21:38:00] <r1chardj0n3s> also mirrors the mac .app approach in some respects which I like

[21:39:41] <r1chardj0n3s> ahh, pispi failed because "devpi" is a meta-package and you need to install "devpi-server" and "devpi-client" explicitly

[21:40:18] <r1chardj0n3s> that splitting of the package doesn't make sense to me - I must ask holger why he did it some day

[21:42:56] <dstufft> r1chardj0n3s: makes sense, it only wants to install the CLI for the primary thing, not any of it's dependencies

[21:43:08] <r1chardj0n3s> yeah, but it's so small ;)