Log file Viewer

[00:05:27] <glassresistor> is there any examples or software that upgrades 2 code to work on both>

[00:05:40] <glassresistor> like 2to2and3

[00:16:51] <dstufft> glassresistor: python-future or python-moderize

[00:17:54] <glassresistor> dstufft: thanks i'll check it out

[10:14:45] <mitsuhiko> heyho

[10:14:57] <mitsuhiko> does anyone know if there are known issues with virtualenv on ubuntu 14.04?

[10:15:19] <mitsuhiko> it looks like pip tries to install system wide

[10:19:09] <xafer> dunno, running ubuntu 14.04 and virtualenv everyday without issue

[10:32:17] <mitsuhiko> well, problem went away after no longer using system virtualenv

[19:33:18] <nanonyme> How exactly do those wheels that are supposed to work with multiple Python versions work?

[19:33:58] <nanonyme> Ie how do you define what's supported etc?

[19:34:32] <nanonyme> Is it jsut that that happens by default if there's no compiled C code involved?

[19:37:06] <nanonyme> http://lepture.com/en/2014/python-on-a-hard-wheel whoa :D

[19:37:53] <nanonyme> dstufft, reckon that'd be some food for some new functionality into wheel? :)

[19:40:13] <dstufft> I think pip 1.6 treats OSX as >= for the sdk version

[19:52:13] <nanonyme> Also, I was thinking of a reverse-wheeling; do you think that could be a doable thing?

[19:53:02] <nanonyme> Ie such if you have a virtualenv, you could (with a mystic new functionality) create installable packages back out of the things that were originally installed to it

[19:53:37] <nanonyme> So if they're dropped from PyPI and even if upstream dies, you can still install it if you for some obscure commercial reasons can't update (yet)