Log file Viewer

[01:50:06] <StevenK> lifeless: setuptools released yesterday with packaging 16.4, which picked up another regression. "name >=2, <3" now doesn't parse. If I switch back to MatchFirst() rather than Or(), it does. :-(

[02:23:09] <lifeless> StevenK: are , and ' ' rejected by the legacy version ?

[02:23:15] <vividboarder> tomprince this should be better: https://github.com/pypa/virtualenv/pull/827/files

[02:23:22] <vividboarder> thanks for the suggestions!

[02:38:23] <StevenK> lifeless: Whitespace certainly i

[02:38:25] <StevenK> *is

[02:39:19] <StevenK> lifeless: However, it's really two versions, not one

[02:40:43] <StevenK> I don't think either regex specifies , since they are for single specifiers

[02:41:42] <lifeless> right

[02:41:50] <lifeless> but legacy is specified as a greedy regex

[02:42:04] <lifeless> if it eats the , what will the rest of the grammar do ?

[02:46:39] <StevenK> Hmmmmm, you might be right

[02:47:14] <StevenK> PEP440 matches >= 2 and LEGACY matches >= 2, and wins since it matches one more char, and then there isn't a comma for the grammar

[02:47:42] <lifeless> +1

[02:49:44] <StevenK> Sucess, with adjacent=False in the Combine() call -- otherwise Combine() wants no whitespace

[02:51:55] <StevenK> lifeless: Any other characters you think should be excluded from LegacySpecifier?

[05:27:32] <lifeless> StevenK: I don't know - as I said the other day, anything that the grammar will accept right after a version needs to be excluded from legcyversion

[05:34:23] <StevenK> Right, then that's enough then

[05:52:46] <lifeless> StevenK: spaces, commas, all operators (for use in matchers? - or does the matcher expression use only the modern version ( I think it should)

[05:55:41] <StevenK> For now it's whitespace , ; and )

[12:40:40] <StevenK> dstufft: Thanks for the merge! Can I have a release to toss it into setuptools?

[18:13:05] <sigmavirus24> dstufft: I think StevenK needs a release for https://bitbucket.org/pypa/setuptools/issues/502/packaging-164-does-not-allow-whitepace if you have a minute

[18:42:32] <dstufft> sigmavirus24: StevenK Released 16.5

[18:42:49] <sigmavirus24> dstufft: thanks. I can ping Jason on bitbucket if you'd like

[22:37:50] <burzos> So I have a question about your rude goldberg machine.

[22:38:28] <burzos> pip.pep425tags.get_platform() behavior has significantly changed between 7 and 8

[22:39:05] <burzos> Previously pip was looking at the platform that built the python interpreter to determine if a wheel was compatibile with the system, now it's looking at the current platform the interpreter is running on.

[22:39:12] <burzos> For darwin.

[22:39:59] <burzos> Why is this correct? And is there reason to believe it will stay this way

[22:41:46] <burzos> Because now I need to spin up an old ass system to build my wheels, where before I just needed to make sure my python interpreter was built on a new system.

[22:46:20] <burzos> https://github.com/pypa/pip/pull/3232

[22:46:30] <burzos> In particular, that merge is going to break shit

[23:00:34] <njs> burzos: what's the problem?

[23:01:49] <njs> burzos: before if your interpreter was built on 10.6, and ran on 10.8, then it would only accept wheels built on 10.6 or older; now it should accept wheels built on 10.8 or older. So it accepts strictly more wheels than before, how does this mean you have to build wheels differently?

[23:02:07] <burzos> That's not true.

[23:02:21] <burzos> If my interpreter was built on 10.8 and ran on 10.6 I could accept 10.8-

[23:02:27] <burzos> Now I can only accept 10.6-

[23:03:13] <njs> if your interpreter was built on 10.8 then in general it will crash on startup when running on 10.6?

[23:03:19] <burzos> Works fine.

[23:03:26] <njs> or at least if it does then apple says that's not a bug

[23:03:38] <burzos> Although it's more like, built on 10.11 and being used on 10.10 and 10.11

[23:04:16] <burzos> I'm not saying that the old way is correct, just that the new way is going to break stuff

[23:05:15] <njs> huh

[23:05:30] <njs> this does explain why pip is a rube goldberg machine of sadness

[23:05:52] <burzos> Yeah, that PR is def not backwards compatible

[23:05:54] <njs> "we made the platform checking more reliable and accurate" "BUT I NEEDED IT TO BE WRONG" :-(

[23:06:08] <njs> (sorry, not saying that you're shouting or anything, just... sigh at the situation)

[23:06:20] <burzos> I was just following what limited documentation was available on the subject

[23:06:34] <burzos> The documentation told me that it cared about what platform the python interpreter was built on, so I followed that

[23:07:09] <burzos> But yeah, it sucks

[23:07:29] <burzos> But apparently hasn't affected that many people because I haven't found many more complaints

[23:08:26] <njs> this is the best docs on osx wheels that I know of: https://github.com/MacPython/wiki/wiki/Spinning-wheels

[23:10:00] <njs> and IIUC it recommends using an old 10.6-ish OS X for building wheels (since this is the only officially-supported-by-apple way to do things), and targeting the official python.org interpreter (which IIUC is built on 10.6)

[23:10:40] <njs> so I think most osx wheels on pypi are also built using 10.6, and are unaffected by that merge

[23:13:20] <njs> I guess it would be possible to make pip use max(build platform, runtime platform) as the highest-allowed-wheel-SDK during some deprecation period, but in the long run Apple's rule is that if you want to run on version X you need to build on X-or-lower, and there's not much pip can do about that

[23:17:11] <burzos> Yeah that's the document I read.