pmxbot IRC Log Viewer

[02:22:15] <r1chardj0n3s> dstufft: you about?

[05:17:29] <r1chardj0n3s> so basically, self-check is busted for non-virtualenv users :/

[05:18:00] <r1chardj0n3s> & I only noticed because I --verbose'd to diagnose the snafu I went through yesterday

[06:51:20] <dstufft> r1chardj0n3s: hows it busted?

[09:04:16] <ionelmc> dstufft: 2.6 doesn't haev getsitepackages

[09:04:28] <ionelmc> is 2.6 still worth supporting?

[09:05:06] <dstufft> ionelmc: that is a good question

[09:05:27] <dstufft> certainly 2.6 still gets s respectable amount of traffic

[09:05:32] <dstufft> on pypi

[09:05:51] <dstufft> though that may mean that people who still need 2.6 are stuck on prerewrite

[09:05:58] <dstufft> I'd need to think about that more

[09:11:49] <dstufft> A Year ago new relic said 12% of their apps were on 2.6

[09:12:19] <dstufft> http://blog.newrelic.com/2014/01/21/python-3-adoption-web-apps/

[09:16:06] <dstufft> xafer: CentOS / RHEL?

[09:17:55] <xafer> nope, too conservative ops team...

[09:18:06] <ionelmc> oh come on, even those have 2.7

[09:18:23] <dstufft> ionelmc: well they do in 7

[09:18:26] <dstufft> 6.X only has 2.6

[09:18:28] <ionelmc> i mean SCL is annoying but not as annoying as older python :-)

[09:18:30] <dstufft> and 7 is still newish

[09:18:50] <ionelmc> dstufft: no, centos/rhel 6 have 2.7 via SCL

[09:18:58] <ionelmc> and SCL is made by redhat

[09:19:04] <doismellburning> (fortunately they've shipped their own 2.7 packages)

[09:19:11] <dstufft> hmm I thought SCL was new in 7

[09:19:16] <dstufft> shows how much i know

[09:20:11] <ionelmc> anyway, there may be a way to support 2.6, without manually coding for all the lib paths

[09:21:28] <dstufft> ionelmc: well, even if we drop support for 2.6 in the new stuff, the old things will still exist and we can update it with new pip/setuptools and stuff too

[09:24:22] <ionelmc> doismellburning: SCL is annoying, it requires "activation" (eg, setting all the LD_LIBRARY_PATH and stuff)

[09:24:29] <ionelmc> it's like a virtualenv, haha

[09:25:22] <dstufft> I never understood why they didn't just ship alt installed pythons like the other distros do

[09:25:28] <ionelmc> gha ... 2.6, you have to do pip -m pip.__main__

[09:25:31] <ionelmc> dafuq :-)

[09:25:36] <dstufft> ionelmc: yea 2.6 is terrible

[09:41:57] <ionelmc> dstufft: imo the SCL is the result of bureaucracy, if they did with alts then they'd have to test everything (a lot of effort), while with the SCL they don't (only test that the scls run, no interation with the rest of the system), so they just defer that crap to the users, dealing with breakage when you try to combine the scl with something else in the

[09:41:57] <ionelmc> system

[09:43:36] <ionelmc> and let me tell you, shit will break when you don't have the right LD_LIBRARY_PATH

[09:43:52] <ionelmc> it's not always convenient to set it or use the SCL activation scripts

[09:44:05] <ionelmc> </rant>

[09:54:41] <ionelmc> dstufft: 3.2?

[09:54:46] <ionelmc> please say "no"

[09:55:46] <ionelmc> no one is foolish enough to use the broken 3.x releases right? (3.0, 3.1 and 3.2)

[10:01:07] <dstufft> ionelmc: the biggest reason to keep 3.2 around is PyPy3 is currently only at 3.2

[10:01:14] <dstufft> 3.0 and 3.1 are no

[10:04:21] <ionelmc> dstufft: but on a serious note, does anyone actually use pypy3? i mean it's a nice idea and all, but still ..

[10:05:20] <dstufft> ionelmc: dunno!

[10:05:29] <ionelmc> who knows?

[10:05:32] <dstufft> for 3.2 the question to me is how hard is it to support it

[10:05:35] <ionelmc> Alex_Gaynor: ping

[10:06:04] <dstufft> for most things I do the only downside to support 3.2 is the lack of a u"" prefix

[10:06:31] <ionelmc> dstufft: btw, i've fixed the 2.6 support

[10:06:50] <dstufft> ionelmc: how'd you do it?

[10:07:01] <dstufft> I emailed pypa-dev anyways about dropping support for 2.6 :V

[10:07:20] <ionelmc> dstufft: https://github.com/ionelmc/virtualenv/commit/9d738c5892f765b88f650bbb7bc8857025e7fb25

[10:07:36] <ionelmc> seems to work :-)

[10:07:50] <ionelmc> well see what happens when we have more integration tests

[10:08:23] <dstufft> interesting

[10:09:41] <ionelmc> now there's only pypy and the 3.2 crap failing https://travis-ci.org/pypa/virtualenv/builds/46049294

[10:10:25] <ionelmc> i don't really want to fix it for 3.2, i see no future in it, lots of stuff in crippled in 3.2

[10:10:40] <ionelmc> s/in/is/

[10:14:00] <dstufft> ok

[10:14:40] <ionelmc> unless there's real demand for it it's a waste of time imo

[10:16:38] <dstufft> Is https://github.com/ionelmc/virtualenv/commit/fd4d099850d658896fb8cf9ddaadf0680cd8d1a2 needed? I thought that https://github.com/pypa/virtualenv/blob/rewrite/.appveyor/install.ps1#L10-L57 would just install Python to the correct place either way?

[10:16:47] <xafer> https://github.com/pypa/pip/issues/304 looks like it could be closed

[10:17:21] <ionelmc> dstufft: it is, tox don't know anything about "architecture"

[10:17:46] <dstufft> ionelmc: but I don't think it needs too, won't the code I linked install Python 64bit into C:/pythonXY?

[10:18:40] <ionelmc> hmmm

[10:19:07] <dstufft> oh

[10:19:09] <dstufft> it's commented out

[10:19:09] <dstufft> wtf

[10:19:20] <dstufft> I just copy/pasted that shit from pf_moore's branch on pip

[10:19:43] <dstufft> https://github.com/pypa/virtualenv/blob/rewrite/.appveyor/install.ps1#L80

[10:19:52] <ionelmc> oh lol

[10:20:07] <ionelmc> well, i mean, appveyor is already very slow

[10:20:23] <ionelmc> do you really wanna reinstall stuff you already have?

[10:20:43] <dstufft> I didn't realize it already had it

[10:20:47] <dstufft> I thought we were instlaling it

[10:20:50] <dstufft> and that's why it was sos low

[10:21:18] <ionelmc> dstufft: and if the dir is present it won't do anything anyway https://github.com/pypa/virtualenv/blob/rewrite/.appveyor/install.ps1#L41

[10:21:36] <dstufft> I didn't actually read the body of those functions

[10:21:38] <dstufft> just the name :D

[10:21:47] <ionelmc> it's hacky to install the 64bit over the 32 one anyway

[10:21:47] <dstufft> because my brain can't handle powershell

[10:23:22] <ionelmc> dstufft: i've done the env var trick before, seems to be the most flexible

[10:24:21] <ionelmc> eg, you can fixup exe path for appveyor (like for pypy), without fuxing up the Travis builds

[10:25:10] <ionelmc> we'll need it if we're to support the other more exotic interpreters

[10:28:30] <dstufft> ionelmc: pulled that out into it's own thing ^^

[10:30:15] <ionelmc> dstufft: i think appveyor runs everything serially, not sure what you're achieving :)

[10:30:27] <ionelmc> my build will run before yours hehe

[10:30:44] <dstufft> ionelmc: yours has tests failing and does more

[10:32:40] <ionelmc> hmmmm... the 3.x has some failure

[10:38:55] <ionelmc> dstufft: oh yeah, it fails cause venv is actually _BROKEN_ on 3.x

[10:39:04] <ionelmc> it doesn't install pip in the venv

[10:39:24] <dstufft> ionelmc: with global site packages? or in general?

[10:39:33] <ionelmc> no, in general

[10:39:49] <ionelmc> has some other bugs too

[10:39:50] <dstufft> virtualenv turns off venv installing pip into the virtual environment

[10:39:58] <dstufft> we want to install it ourselves

[10:42:55] <ionelmc> hmmmm

[10:45:06] <ionelmc> dstufft: oh yeah, i forgot, if doesn't install pip if you use --system-site-packages

[10:45:11] <ionelmc> anyway

[10:46:13] <straycat> So, if I've followed this correctly ep.resolve() is to be used instead of ep.load(), so that require is set to False which allows setuptools to continue if the entry point isn't available, is that correct?

[10:46:38] <dstufft> straycat: more or less

[10:48:37] <straycat> Okay cool thanks

[10:53:48] <ionelmc> dstufft: no --isolated on 3.x?!

[10:53:52] <ionelmc> what gives

[10:54:06] <dstufft> ionelmc: wat?

[10:55:44] <ionelmc> dstufft: when was --isolated added?

[10:55:57] <dstufft> it's a pip command

[10:56:03] <dstufft> in 6

[10:58:20] <ionelmc> hahahah

[10:58:30] <ionelmc> dstufft: ok, so venv use symlinks

[10:58:42] <dstufft> hmm

[10:58:46] <dstufft> I thought I told it not to

[10:58:55] <ionelmc> if pip is already installed globally (it is) then pip install is skipped in virtualenv

[10:59:16] <dstufft> yea, I didn't fix that yet

[10:59:26] <dstufft> I think it just need an --ignore-installed passed

[10:59:29] <dstufft> into the pip command

[11:01:42] <ionelmc> dstufft: wohoo, i just upgraded my py3 pip by running the virtualenv test suite :-)

[11:01:52] <ionelmc> actually, downgraded

[11:02:03] <ionelmc> cause the rewrite branch has older 6.0.3

[11:02:13] <ionelmc> so no, --ignore-installed is no option

[11:04:45] <ionelmc> dstufft: http://bugs.python.org/issue18807

[11:06:21] <dstufft> ok

[11:06:35] <ionelmc> it's not that

[11:06:37] <ionelmc> hmmm

[11:10:38] <ionelmc> somehow pip is getting confused by venv and things the virtualenv has pip (when it's only installed globally)

[11:10:48] <ionelmc> dstufft: looks like a pip bug to me

[11:11:11] <dstufft> I'll take a look

[11:15:08] <ionelmc> https://www.irccloud.com/pastebin/WYT95zU1

[11:15:49] <ionelmc> https://www.irccloud.com/pastebin/WEBimpHF

[11:53:35] <ionelmc> dstufft: why don't i get mail notifications for pr build results?

[12:01:27] <dstufft> ionelmc: dunno

[12:16:29] <ionelmc> dstufft: this has to be the most mindboggling failure: https://travis-ci.org/pypa/virtualenv/jobs/46062725

[13:25:47] <collinanderson> ionelmc: it is in there twice, right?

[13:26:18] <ionelmc> collinanderson: yes, it was the hidden merge that travis did (was broken)

[14:50:22] <pmxbot> jaraco pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :

[14:50:22] <pmxbot> Restore support for printable characters in the entry point name. Fixes #327.

[15:10:45] <pmxbot> jaraco pushed 4 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[15:10:45] <pmxbot> Equal signs are now allowed in entry point names.

[15:10:45] <pmxbot> Refactor for clarity

[15:10:45] <pmxbot> Use pytests parametrize to create separate tests for each spec

[15:10:45] <pmxbot> Use pytest.raises for brevity and clarity of purpose.

[15:14:15] <pmxbot> jaraco pushed 3 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[15:14:15] <pmxbot> Bumped to 11.3.1 in preparation for next release.

[15:14:15] <pmxbot> Added tag 11.3.1 for changeset 1116e568f534

[15:14:15] <pmxbot> Bumped to 11.3.2 in preparation for next release.

[15:17:05] <Alex_Gaynor> ionelmc: pong

[15:28:27] <ionelmc> Alex_Gaynor: how much use pypy3 has?

[15:28:42] <Alex_Gaynor> ionelmc: In terms of production use you mean?

[15:30:02] <ionelmc> Yeah

[15:30:11] <ionelmc> Is it worth supporting?

[15:30:31] <sigmavirus24> ionelmc: supporting pypy3 should be as difficult as supporting python 3.2

[15:30:39] <ionelmc> Cause py3.2 has some inconveniences

[15:30:41] <Alex_Gaynor> I don't have any evidence, but I think it's probably smaller than PyPy2.

[15:30:45] <Alex_Gaynor> This is for virtualenv?

[15:30:56] <ionelmc> Yes

[15:31:12] <Alex_Gaynor> I'd prefer you didn't.

[15:31:19] <Alex_Gaynor> If virtualenv drops pypy3 it makes it MUCH harder to use

[15:31:24] <Alex_Gaynor> including for platforms likje travis-ci

[15:38:38] <msabramo> jaraco: setuptools v20 by the end of 2015? :-)

[15:43:50] <ionelmc> Alex_Gaynor: how is 3.4 support going?

[15:44:14] <Alex_Gaynor> ionelmc: we're doing 3.3 first -- you'd have to ask amaury or pjenvey in #pypy for the status

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Tuesday the 6th of January, 2015