Log file Viewer

[01:04:34] <r1chardj0n3s> 225 nested list printers nuked

[01:04:57] <r1chardj0n3s> (and one false-positive generating bug fixed)

[01:06:40] <dstufft> \o/

[01:06:49] <dstufft> but r1chardj0n3s where will I get my nested list printers now

[01:07:12] <r1chardj0n3s> buy the book ;)

[02:50:07] <Alex_Gaynor> dstufft: we never did figure out https://github.com/pypa/pip/pull/1878 did we?

[02:50:23] <dstufft> Alex_Gaynor: nope

[02:50:29] <dstufft> I'm poking at PRs again

[02:50:33] <dstufft> i'm going to rerun the tests

[02:50:36] <dstufft> in a few

[02:50:50] <Alex_Gaynor> k

[02:51:07] <dstufft> I still need to talk to glyph about that I guess. Maybe we need to split out our functional test suite into it's own thing so it's not dependent on the version of python we're testing

[02:51:13] <dstufft> and use something other than subprocess for it

[03:43:44] <dstufft> looks like it's still happening (I figured it would, but I wanted to try anyways)

[03:48:03] <r1chardj0n3s> programmers are so terrible "no use wheel" indeed :)

[03:48:14] <r1chardj0n3s> (yes, I know why it's called that ;)

[03:53:25] <dstufft> lol

[03:53:31] <dstufft> I named it that >:[

[03:54:03] <r1chardj0n3s> as I said, I understand why it's named like that (because patterns make sense)

[03:54:17] <r1chardj0n3s> also —don't-use-wheel wouldn't work ;)

[08:21:08] <jezdez> we should totally use --do-not-for-the-love-of-everything-holy-use-wheels

[08:21:23] <jezdez> and shortcut it with -d

[08:21:26] <jezdez> :P

[11:39:36] <agronholm> is there any way I can include conditional dependencies in a wheel? like installing "futures" for python <3.2

[13:25:32] <dstufft> agronholm: https://github.com/dstufft/twine/blob/master/setup.cfg#L9-L13

[13:25:41] <dstufft> agronholm: this only takes affect for wheel

[13:26:15] <agronholm> cool, is this documented?

[13:26:55] <dstufft> no idea

[13:27:07] <agronholm> seems like a very useful feature, so it should be

[13:29:51] <agronholm> I get a warning that setup.cfg requirements overwrite values from setup.py

[13:30:08] <agronholm> but what other choice do I have if I want to offer both an sdist and a wheel?

[13:30:44] <dstufft> all that's telling you is that your setup.cfg requirements have to be everything

[13:30:59] <agronholm> of course

[13:31:00] <dstufft> e.g. you can't put jsut the conditional stuff in there and expect it to fall back to install_requires for wheel

[13:31:09] <dstufft> that's all

[13:31:11] <agronholm> right

[13:31:23] <dstufft> and it's the only way to do conditional afaik atm

[13:31:39] <agronholm> thanks

[15:59:27] <dstufft> jaraco: ping

[16:20:53] <jaraco> dstufft: pong

[16:22:57] <dstufft> jaraco: PEP 440 defines what a version looks like and what version specifiers look like, it's not accepted yet but I'm trying to push to get it finished. Would you be OK with a PR to setuptools (once it is accepted) that implements it? It's techincally backwards incompatible in that instead of allowing just anything to be a version (including stuff like "dog" and "boat") it restricts the versions down to a specific grammar, but it achieves

[16:22:57] <dstufft> high compat with the versions that exist on PyPI today ((96.81%) of versions can be parsed)

[17:22:32] <jaraco> dstufft, 97% seems low, but I'm guessing the 3% is all long tail stuff. I do worry about PEPs like 440 w.r.t. packages like pytz which have a clear and justifiable precedent that violates the new mandate.

[17:22:38] <jaraco> But I haven't reviewed PEP 440 lately.

[17:23:11] <dstufft> jaraco: so pytz has been using PEP 440 compat versions since uh, 2013 or so

[17:23:25] <jaraco> In any case, to the extent that the community settles on PEP440, setuptools should implement that.

[17:23:31] <dstufft> the old versions are not compat ofc

[17:23:35] <dstufft> but all the new ones are

[17:23:40] <jaraco> And any pull request in that regard would be readily accepted, even if it has backward-compatibility concerns.

[17:23:49] <dstufft> ok cool

[17:23:55] <tomprince> setuptools 6.x :)

[17:24:26] <jaraco> If it's going to break installation of certain packages, that would be a big concern.

[17:24:42] <jaraco> But if it's primarily about building/uploading of newer packages, that's less of a concern.

[17:25:17] <dstufft> the remaining 3% is a lot of long tail stuff, some of it is completely nonensical stuff, some of it is things we could conceivelably capture, but each additional rule onlly gets a few extra versions into the fold and the complexity started getting high

[17:25:42] <dstufft> jaraco: oh PEP 440 also allows people to fall back to implementation defined behavior

[17:25:49] <dstufft> if stuff can't be parsed

[17:25:59] <jaraco> All sounds sane and good.

[17:26:02] <jaraco> !rubberstamp

[17:26:02] <pmxbot> Bad credit? No credit? Slow credit? APPROVED!

[17:27:17] <dstufft> the primary thing I'm really worried about in setuptools is the new specifiers vs the redefinition of the existing specifiers or strict usage of PEP 440 semantics (although it'd be great to make it a tleast understand it, even if it wasn't strict about requiring it)

[17:27:28] <dstufft> PEP 440 adds ~= === and ==1.*

[17:27:45] <dstufft> which can't be used in install_requires really unless setuptools adds support

[17:28:21] <jaraco> right

[17:29:13] <dstufft> oh and for the compatability concerns, === is basically "yea the thing I want to install isn't PEP 440 compat, so don't parse versions as PEP 440 and jsut do basic string equality"

[17:30:18] <dstufft> but cool, at least there's some level of sign off on it so I don't have to worry about a split once PEP 440 is accepted, thanks jaraco !

[17:30:27] <jaraco> yw

[17:30:40] <jaraco> !m dstufft

[17:30:40] <pmxbot> you're doing good work, dstufft!

[17:31:33] <dstufft> If you're interested, here's the current compat numbers (based on versions on PyPI) http://bpaste.net/show/NYsRASpMo47XFsBuiUo3/

[17:31:39] <dstufft> that's PEP 440 vs pkg_resources

[22:31:34] <dstufft> glyph: ping