Log file Viewer

[03:11:34] <prometheanfire> wooo

[03:16:22] <dstufft> prometheanfire: whats up?

[03:17:00] <prometheanfire> dstufft: nothing much, just saying hi

[03:17:08] <dstufft> heya :D

[03:17:09] <prometheanfire> bunch of openstacky things

[03:17:11] <prometheanfire> :D

[10:57:34] <lazka> is pypi down? trying to edit my packages times out

[10:57:43] <lazka> "Something went wrong"

[11:01:48] <FRidh> lazka: yep so it seems: https://bitbucket.org/pypa/pypi/issues/442/500-server-error-trying-to-register

[11:02:18] <FRidh> xmlrpc is not responding either

[11:02:20] <lazka> FRidh, thanks

[12:01:54] <|RIC|> hi

[12:02:00] <|RIC|> can any one help

[12:02:16] <|RIC|> sudo pip install scipy

[12:02:24] <|RIC|> warning using deprecated numpy api

[12:02:34] <|RIC|> unable to install scipy

[14:25:11] <Ergo> hey guys, it seems that both pypi and warehouse are experiencing problems right now

[14:25:28] <Ergo> I can't edit my packages at all, and https://pypi.io/ is down too

[14:34:46] <FRidh> Ergo, indeed: https://bitbucket.org/pypa/pypi/issues/442/500-server-error-trying-to-register

[16:45:01] <gsnedders> Is there any way to have requirements files that support both old and current setuptools versions given the change from "platform_python_implementation" and "python_implementation"?

[16:49:18] <dstufft> gsnedders: I think setuptools restored compatbility with that

[16:49:35] <dstufft> e.g. there is a few setuptools versions in there that no, there isn't, but the newest ones support both

[18:15:01] <gsnedders> dstufft: I thought that looking at the version changes, but the latest still gives 'SyntaxError: invalid expression: python_implementation'

[18:15:28] <gsnedders> dstufft: packaging bug that should be fixed?

[18:16:27] <dstufft> gsnedders: probably yea

[18:17:15] <gsnedders> kk

[18:18:00] <gsnedders> It kinda sucks, esp. if any distros have shipped with a broken version of setuptools

[18:19:20] <gsnedders> dstufft: https://github.com/pypa/setuptools/issues/503 makes it look like it should be fixed, given https://github.com/pypa/packaging/issues/70 is explicitly python_implementation

[18:19:42] <gsnedders> oh, is that "platform.python_implementation"?

[18:19:45] <dstufft> that's platform.python_implementation

[18:19:59] <gsnedders> yeah, it is

[18:23:39] <gsnedders> dstufft: oh, this stuff in html5lib comes from your PR anyway when all this stuff around requirements was totally undocumented anywhere :)

[18:24:06] <gsnedders> dstufft: (I mean except for the PEP 345 stuff, which obviously doesn't directly apply)

[18:25:15] <dstufft> Markers has a sordid history of like 3 different implementations implementing slightly different things

[18:26:19] <gsnedders> yeah, I've learnt that over the past few days…

[18:26:48] <dstufft> packaging should hopefully support all the old shit for legacy reasons

[18:26:50] <dstufft> I guess we missed some

[18:27:24] <gsnedders> hardly surprisingly, really

[18:30:13] <dstufft> MOVE FAST(ER) AND BREAK THINGS

[18:45:35] <gsnedders> https://github.com/pypa/setuptools/commit/3bd5118eaa87b4f6598e0a473fec3623b6579d3b — that changes pkg_resources/_vendor/packaging/markers.py, but I can't find a corresponding change in the packaging repo?

[18:47:44] <gsnedders> oh, right, it's the fact that setuptools did some unidifcation of markers before the upstream packaging did?

[18:47:56] <gsnedders> but that history is only reflected in the setuptools repo?

[19:12:43] <gsnedders> dstufft: https://github.com/pypa/packaging/issues/72 I think is a summary of it, FYI

[19:24:02] <dstufft> gsnedders: A+ looks good

[19:38:53] <gsnedders> …and there's now a PR fixing it.

[19:39:54] <dstufft> Awesome, thanks!

[19:41:16] <dstufft> Hm

[19:41:23] <dstufft> I wonder if we should normalize these legacy things

[19:41:32] <dstufft> right now we'll parse them, but never actually evaluate them

[19:42:26] <dstufft> making it an error to actually use them unless the caller of Marker().evaluate() passes them in

[19:42:56] <dstufft> which seems less useful than if we jsut added them to the default environment as aliases (or normalized them internally to the non-legacy name)

[19:44:07] <gsnedders> I feel like there's a fair bit of complexity around this code I haven't got my head around

[19:45:09] <gsnedders> also my PR is badly broken

[19:45:13] <gsnedders> because I'm a numpty

[19:45:21] <gsnedders> The test is literally useless.

[19:46:30] <gsnedders> (it uses the PEP 345 syntax!)

[19:47:02] <gsnedders> dstufft: how does platform.python_implementation work from platform_python_implementation in the environment?

[19:47:49] <gsnedders> dstufft: see the platform.python_implementation test

[19:48:27] <dstufft> gsnedders: yea that's basically what I was just saying right now. Right now the parser won't choke on parsing something that uses any of the legacy specifiers, but we don't include values in the default environment, so actually attempting to evaulate them will result in an error unless the caller of Marker().evaluate() passes in a value for them

[19:48:40] <dstufft> any (sans the one we forgot that you just added)

[19:49:32] <gsnedders> like, that pep345 test passes despite it passing it in a different format

[19:49:39] <gsnedders> indeed all of those use different formats?

[19:50:29] <dstufft> I'm not sure what you mean

[19:51:31] <gsnedders> You'd expect Marker("platform.python_implementation=='Jython'").evaluate() to error, right, because "platform.python_implementation" isn't in the default environment?

[19:52:43] <gsnedders> However, it doesn't. It works fine.

[19:53:56] <gsnedders> oh

[19:54:04] <gsnedders> it gets normalised to the normal syntax

[19:54:16] <gsnedders> by the variable parse action

[19:54:31] <dstufft> oh

[19:54:32] <dstufft> I see

[19:54:36] <dstufft> I missed that too

[19:55:08] <dstufft> so that parse action handles all the differences where it was . -> _

[19:55:12] <gsnedders> right

[19:55:38] <dstufft> yours is different though, because it needs a whole rename

[19:56:42] <gsnedders> Indeed. And I dislike the idea of cramming it all in the parse action.

[19:57:47] <dstufft> https://bpaste.net/show/bb147703c5d7 is one idea

[19:58:09] <dstufft> could remove the .replace and just list them all in aliases too

[19:58:19] <dstufft> which might make it more obvious for the next person

[19:58:32] <gsnedders> Aye, I think the explicit solution is the better one

[20:00:41] <gsnedders> dstufft: any opinion ebtween VARIABLE_ALIASES and ALIASES?

[20:01:18] <dstufft> gsnedders: not really

[20:01:21] <dstufft> whatever is fine

[20:27:19] <gsnedders> dstufft: ok, PR now has everything working

[20:28:46] <dstufft> gsnedders: looks good to me

[20:29:48] <dstufft> gsnedders: are you planning to squash the fixup! fixup! commits? I'm not sure what your comment was referencing :]

[20:30:00] <gsnedders> dstufft: just breaking the lambda like this is hella ugly

[20:31:06] <gsnedders> dstufft: okay, squashed now

[20:31:31] <dstufft> gsnedders: looks good, will merge once tests pass

[20:32:45] <dstufft> gsnedders: Do you plan on going to poke setuptools to pull in the new code? (I assume you are, but just checking)

[20:34:28] <gsnedders> dstufft: I thought you only did that on release?

[20:34:45] <dstufft> gsnedders: I was going to cut a release right now if you were planning on doing that :]

[20:34:52] <gsnedders> dstufft: then I will do that :)

[20:37:23] <gsnedders> dstufft: https://bitbucket.org/pypa/setuptools/issues/503 gives an access denied BTW which is annoying trying to work out the history of this, presumably because you have issues disabled… would be really nice to have a read-only mode :(

[20:37:48] <dstufft> gsnedders: I'm not actually a committer on setuptools so idk what jaraco did

[20:38:01] <gsnedders> oh, I thought you were :)

[20:38:04] <dstufft> I mean

[20:38:12] <dstufft> techincally I have a commit bit because I'm an admin on the pypa org

[20:38:19] <dstufft> but I'm not "a committer"

[20:50:44] <gsnedders> dstufft: any ETA for teh release?

[20:51:51] <dstufft> gsnedders: half way through the process now, but gotta run to the store real quick

[20:51:54] <dstufft> will finish it when I get back

[20:55:26] <gsnedders> dstufft: ok, sure, I may push off setuptools PR to tomorrow, FYI

[21:14:16] <gsnedders> Related to all this: there's no way to give a requirement on setuptools<20.2 or >= 20.6.6 is there?

[21:41:54] <gsnedders> dstufft: wait, we still have https://github.com/pypa/pip/blob/develop/pip/_vendor/distlib/markers.py too

[21:41:57] <gsnedders> argh

[21:43:53] <dstufft> gsnedders: don't think anything uses distlib for that

[21:44:30] <gsnedders> dstufft: pip does

[21:44:39] <dstufft> we use distlib for markers?

[21:44:49] <dstufft> I thought we only used it for writing out the script wrappers

[21:45:40] <gsnedders> dstufft: https://github.com/pypa/pip/blob/develop/pip/req/req_install.py

[21:46:01] <dstufft> oh

[21:46:02] <dstufft> well

[21:46:08] <dstufft> obviously that should just switch to using packaging :]

[21:46:23] <gsnedders> yes.

[21:48:27] <dstufft> now to figure out why my upload is timing out

[22:28:37] <dstufft> gsnedders: https://pypi.io/project/packaging/

[22:50:19] <gsnedders> dstufft: yay

[22:50:34] <gsnedders> dstufft: looking at some of the pip fun now