pmxbot IRC Log Viewer

[00:09:15] <paulproteus> I would like to attend a SF-based PyPA sprint sometime.

[00:09:55] <paulproteus> I would happily work on things on a day-long weekend sprint like that. Is this something that glyph (hmm curiously missing) or Alex_Gaynor or coderanger (hmm, curiously missing) might attend?

[00:10:05] <paulproteus> (or other SFBA peeps)

[00:10:26] <Alex_Gaynor> I'd probably show up, are you volunteering to organize :-)

[00:10:40] <paulproteus> Yes, I am (:

[00:10:45] <paulproteus> It would likely be in June, at this rate.

[00:10:51] <paulproteus> Maybe late May.

[00:11:10] <Alex_Gaynor> Ok. If you don't already have space organized, probably glyph/myself/ying/david can make that happen

[00:11:35] <paulproteus> I was thinking Flying Pig Bistro, but Eventbrite could work, or something magically acquired by y'all.

[00:12:01] <Alex_Gaynor> I'm flexible, wherever

[00:12:05] <paulproteus> bd (two thumbs up)

[00:12:10] <Alex_Gaynor> Do you have a particular theme for the sprint?

[00:12:28] <paulproteus> I'd be open to creating a theme. I have none in mind yet, except "usability and documentation".

[00:12:45] <Alex_Gaynor> that's a pretty good theme

[00:13:25] <paulproteus> this ain't a theme, it's an arms race <https://www.youtube.com/watch?v=GNm5drtAQXs>

[00:14:12] <paulproteus> (:

[00:19:38] <wickman> i'd also be down for such a thing.

[00:57:09] <paulproteus> rockin' wickman!

[08:33:19] <Ivo> paulproteus: http://packaging.python.org/en/latest/future.html#major-todos

[08:34:22] <Ivo> paulproteus: getting people to read over PEPs together and talk about whether they make sense, look good, anything looks funny, anything looks missing would also be a great use of time, IMHO

[13:55:33] <pf_moore> Looks like commit bd127f8aba from 8 months ago might be what stopped the pip tests working on Windows :-( We really need some sort of CI on a Windows platform...

[13:58:19] <dstufft> pf_moore: I started setting up infrastructure over the weekend, my goal is to get some CI laid down for windows

[14:00:18] <pf_moore> dstufft: fantastic, if you need any help let me know

[14:01:07] <pf_moore> BTW, on further investigation, I may be wrong about that commit, but it does look like some nasty confusion between pip's Path object and py.test using py.path objects...

[14:01:26] <pf_moore> No idea why it would be Windows specific :-(

[14:13:27] <pf_moore> I'm baffled by the pip tests.PipTestEnvironment is a subclass of scripttest.TestFileEnvironment

[14:13:41] <pf_moore> __init__ calls self.temp_path.mkdir()

[14:14:00] <pf_moore> but temp_path comes from scripttest and is a pure string not a Path object

[14:14:09] <pf_moore> how can that ever have worked?

[14:17:32] <dstufft> pf_moore: heh

[14:17:33] <dstufft> I bet

[14:17:40] <dstufft> this is why

[14:17:58] <dstufft> https://github.com/pypa/scripttest/blob/master/scripttest.py#L162

[14:18:16] <dstufft> self.base_path is going to be a Path object

[14:18:40] <dstufft> I bet on non Windows os.path.join is implemented in a way that preserves the Path object-ness

[14:18:44] <dstufft> (accidently)

[14:18:50] <pf_moore> Ah, that'll be it.

[14:18:51] <dstufft> and on Windows it's not

[14:19:08] <pf_moore> The error comes from splitdrive, which calls len() on a path

[14:19:10] <dstufft> the best thing to do is probably self.temp_path = Path(self.temp_path)

[14:19:36] <pf_moore> yeah, probably

[14:19:56] <pf_moore> This is likely why people say that Path objects subclassing strings are a source of errors...

[14:20:10] <pf_moore> Too easy for them to become strings again by accident

[14:20:19] <pf_moore> thanks, I'll try that suggestion

[14:23:25] <Ivo> can we not just use pytest's tmpdir

[14:25:52] <pf_moore> dstufft: Nope, Path's __new__ also uses os.path.join which fails. So it's going to be an even bigger job to fix. Sigh.

[14:26:30] <pf_moore> Ivo: problem is, tmpdir returns py.path.Local objects, we use pip.Path objects, and the os functions use strings.

[14:26:49] <pf_moore> Compatibility hell :-(

[14:26:53] <dstufft> tmpdir shouldn't return a py.path.Local object

[14:26:56] <dstufft> we override it

[14:27:04] <dstufft> https://github.com/pypa/pip/blob/develop/tests/conftest.py#L32

[14:28:00] <pf_moore> Yes, it's that Path(tmp) call that fails, because Path.__new__ does os.path.join, which calls splitdrive, which calls len on tmp, which (apparently) doesn't support len()

[14:28:21] <dstufft> pf_moore: oh it fails on the line I linked?

[14:29:37] <pf_moore> dstufft: yes, via https://github.com/pypa/pip/blob/develop/tests/lib/path.py#L39

[14:30:09] <pf_moore> which calls if len(p) > 1: in ntpath.py:splitdrive

[14:30:18] <dstufft> pf_moore: maybe just do Path(str(tmp))

[14:30:40] <pf_moore> Tried that. Maybe not with also forcing temp_dir back to a Path object. Let's see

[14:37:46] <pf_moore> dstufft: combining the two fixes seems to have resolved the test failures. Thanks for the help - PR incoming 😃

[15:41:39] <mattip> hi. is there anything I can do to move a virtualenv pull-request forward in the queue?

[15:42:34] <mattip> pull request 595 fixes PyPy on windows, and we are close to releasing PyPy 2.3

[15:59:29] <pf_moore> mattip: It looks OK to me, but only because it's guarded by an "if is_pypy" test, as I don't have PyPy available. Trouble is we don't have any devs with Windows and PyPy experience :-(

[15:59:59] <pf_moore> Why is the PyPy release relevant? The change isn't version-specific is it?

[16:46:21] <mattip> pf_moore: it si relevant because we get a spike in new users around a release, since it makes waves

[16:46:46] <mattip> and people try it out, and the first thing they want to try is numpy,

[16:47:06] <mattip> and the way to try numpy is to set up a virtualenv :)

[16:47:52] <mattip> as for testing, I could suggest

[16:48:36] <mattip> - download a pypy nightly from http://buildbot.pypy.org/nightly/trunk/pypy-c-jit-latest-win32.zip

[16:48:44] <mattip> - unzip

[16:49:50] <mattip> - create a virtualenv "c:\python27\scripts\virtualenv -p <path to pypy>\pypy.exe dummy"

[16:49:59] <mattip> - watch it fail

[16:50:20] <mattip> - try with the patch, watch it succeed.

[16:59:40] <pf_moore> mattip: thanks - tbh, I believe you re the basic it fails/it works check

[17:00:21] <pf_moore> tbh, I'm tempted to just merge on the basis that we don't have anyone better placed to validate that it's OK than you are

[17:01:01] <pf_moore> any pypa people object? if not, I'll merge later this evening

[17:02:29] <DanielHolth> lgtm

[17:15:02] <mattip> too bad travis-ci does not do windows

[17:25:37] <yusuket> dstufft: I ran into some issues with the sqlalchemy transactions. I’ve made some comments, let me know if you have a chance to look over it

[17:25:39] <yusuket> https://github.com/pypa/warehouse/pull/299

[17:26:33] <yusuket> in one sentence: the current way that warehouse has an instance that contains and engine doesn’t allow very clean transactions, my suggestion is to refactor to pass in connection objects instead

[17:26:53] <yusuket> warehouse db apis are instances that have an engine*

[18:17:27] <DanielHolth> yusuket the connection is what I'd be passing too

[18:19:02] <yusuket> DanielHoth: cool! It definitely seems like the right pattern

[18:19:16] <yusuket> DanielHolth: ^

[18:20:25] <DanielHolth> actually I like to pass the DBSession() instance

[18:20:40] <DanielHolth> for orm. Although that includes the (maybe lazily created?) connection

[18:21:10] <DanielHolth> I'm sure warehouse is too hip to use these "orm" things

[18:21:10] <yusuket> yeah, I think that Session creates a connection under the hood

[18:21:18] <DanielHolth> Too convenient

[18:21:34] <yusuket> haha it doesn’t use the orm, although I found sqlalchemy core pretty straightforward too

[18:22:29] <yusuket> at my job we write mappers to stored procedures, so any on-the-fly query generation is a luxury for me :)

[18:28:43] <DanielHolth> and I think you can compile the queries just once in sqla if you want

[18:32:45] <yusuket> ohhh that’s awesome. Definitely a good optimization to add in

[18:34:29] <DanielHolth> Maybe, maybe not. I don't know where warehouse spends it time.

[18:37:07] <yusuket> good point. It seems like everything is aggressively cached, so unlikely that db queries will become a bottleneck

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Monday the 28th of April, 2014