Log file Viewer

[15:21:57] <dstufft> https://twitter.com/tef/status/468406796584243200 sad but true

[15:44:25] <Ivoz> they can also handle character sets other than ascii

[15:45:03] <jezdez> sigh

[15:45:32] <jezdez> dstufft: https://twitter.com/tomlazar/status/468393501517185024 :(

[15:45:39] <Ivoz> oh, and arbitrarily long file names

[15:47:43] <Ivoz> jezdez: its fine if <software> doesn't want to be a python package, but then for the love of god don't have it rely on pip to install itself

[15:48:16] <jezdez> Ivoz: agreed

[15:48:30] <jezdez> it *does* work if you sudo install it

[15:48:50] <Ivoz> go and be a big boy and make a .deb of yourself or something

[15:50:37] <Ivoz> jezdez: oh man, you missed a period in https://twitter.com/jezdez/status/468397755283816449

[15:50:58] <jezdez> Ivoz: I know! I was angry at myself afterwards as well

[15:51:05] <jezdez> but then I went have a coffee and forgot about it

[15:51:14] <jezdez> *shrug*

[15:52:18] <Ivoz> I forgive you this time

[15:54:34] <jezdez> interesting, an "enterprise" product that uses wheels: https://rhodecode.com/blog/45/how-we-improved-python-packaging-distribution

[15:55:15] <dstufft> Ivoz: we could theortically handle character sets other than ascii, we just chose not to

[15:55:31] <dstufft> ditto on arbitrarily long file names

[15:56:05] <Ivoz> actually, the one thing the warez scene doesn't give a shit about it backwards compatibility

[15:56:19] <Ivoz> you can make a lot of progress when free of that constraint

[15:56:24] <dstufft> yea

[15:57:17] <dstufft> I've been re-implementing PEP440 this weekend :V

[15:57:31] <jezdez> oh boy

[15:57:38] <jezdez> lemme guess, you found more edge cases?

[15:58:01] <Ivoz> You mean Vinay's implementation wasn't awesome enough!?

[15:58:14] <dstufft> well, I found some things. some were underspecifications, some were things that I think should change

[15:58:36] <dstufft> found a legit incompatibillity with how pkg_resources vs PEP440 orders things

[15:58:42] <dstufft> not a very major one though

[15:58:51] <Ivoz> dstufft: you should write them down as dot points in a md file

[15:58:58] <dstufft> Ivoz: I opened issues for them

[15:59:06] <Ivoz> well shit

[15:59:10] <dstufft> https://bitbucket.org/pypa/pypi-metadata-formats/issues?status=new&status=open

[15:59:51] <jezdez> :-/

[15:59:53] <dstufft> https://bitbucket.org/pypa/pypi-metadata-formats/issue/37/ordering-of-local-segments is the one I think is most important

[16:00:06] <dstufft> not having a determnistic sort of a set of versions is a non starter IMO

[16:02:17] <Ivoz> dstufft: don't local versions look like numbers, in which case lexicographic would be confusing?

[16:02:28] <dstufft> Ivoz: local versions are now alphanumerics

[16:02:33] <dstufft> and . _ +

[16:03:50] <dstufft> If folks are interested - https://github.com/dstufft/packaging/pull/1

[16:04:04] <dstufft> it only runs like 17k tests

[16:07:37] <Ivoz> dstufft: where does it say that

[16:08:36] <dstufft> Ivoz: that might not be updated yet, Nick said he was going to do it

[16:08:45] <Ivoz> booo

[16:13:17] <dstufft> specifiers support combining them in this

[16:13:21] <dstufft> which is pretty nice I think

[16:13:51] <dstufft> (Specifier(">=2.0") & Specifier("!=2.1")) == Specifier(">=2.0,!=2.1")

[16:14:05] <Ivoz> The only thing I can think of is that pip could allow a plugin to define the local version ordering

[16:14:55] <Ivoz> because inevitably the local version is for other systems by other people, and how some people will want to order them will be incompatible to others

[16:15:18] <dstufft> eh

[16:15:21] <dstufft> I don't see a point

[16:15:36] <Alex_Gaynor> YAGNI

[16:15:38] <dstufft> worse case someone can kludge it

[16:15:39] <Ivoz> well my point is there is no sensible ordering for local versions

[16:15:53] <dstufft> correct, and we don't need one

[16:15:58] <dstufft> we just need a deterministic one

[16:16:00] <Ivoz> Alex_Gaynor: I'd go YAGNI on the entire concept of local versions

[16:16:05] <dstufft> well

[16:16:08] <dstufft> except we do need it

[16:16:11] <Ivoz> unless thats what you meant in the first place

[16:16:31] <dstufft> pip 1.5.4 is in ubuntu, but it's not the real pip 1.5.4, it's pip 1.5.4 with some ubuntu patches

[16:16:55] <dstufft> right now pip --version will say "1.5.4" and we're left going "well is it the _real_ pip, or the ubuntu pip?"

[16:17:08] <dstufft> with local versions, you can do something like pip 1.5.4-ubuntu1

[16:17:15] <Ivoz> sure, but may devils weep upon those who use ubuntu's 1.5.4 pip in something other than ubuntu

[16:17:41] <Ivoz> and try to install it with pip rather than apt

[16:17:55] <Ivoz> and upload it to pypi

[16:17:59] <dstufft> this isn't just about installing, it's about identifiying the code that is being used

[16:18:04] <dstufft> PyPI won't allow local version uploads

[16:18:49] <dstufft> If we can't agree that you shouldn't have two different files, with different contents both equal to the exact same version then idk what to say

[16:19:33] <Ivoz> i was thinking about what to do with their ordering

[16:19:56] <Ivoz> which is what your issue that yuou linked is about

[16:20:17] <dstufft> well ordering matters, because sometiems you do install local versions (besides the fact that we sort the installed version in with the found versions and that needs to be deterministic too)

[16:20:19] <dstufft> for instance:

[16:21:31] <dstufft> I need to fix a bug in pip, maybe I'm jimbaker and I want it to work on Jython :) I could A) Patch it and not change the version (confusing, because now you have two different things with the same version again) B) Pick an arbitrary other version and hope pip never releases something with that version or C) Use a local version and put it up on a private index that I install from (or even find-links)

[16:22:33] <dstufft> instead we could have pip-1.5.6-jython1

[16:22:49] <dstufft> and then it's obvious that this isn't the actual pip 1.5.6, it has modifications

[16:24:36] <Ivoz> actually i regret mentioning it since you guys seem to have reached an acceptable solution in the comments of the issue anyway :/

[16:25:22] <dstufft> :)

[16:26:43] <Ivoz> some days i just wish pep 440 was just semver

[16:27:36] <dstufft> heh

[16:27:47] <dstufft> semver would make a lot of peoples days miserable

[16:28:18] <Ivoz> they shall be martyrs

[16:30:41] <dstufft> turns out semver is simplistic and not able to be globally applied :]

[16:31:26] <Ivoz> we will weep for their glorious sacrifice to simplify package versioning

[16:32:03] <dstufft> I wonder how many projects are actually able to be parsed with a semver project

[16:32:09] <dstufft> that'd be an interesting experiment

[16:33:00] <Ivoz> meta-language-index-analysis?

[16:33:25] <dstufft> heh

[16:40:30] <Ivoz> dstufft: whats your end motive for writing code to parse pep440

[16:41:43] <Ivoz> just get pip to use it?

[16:42:31] <dstufft> Ivoz: *shrug*

[16:42:46] <dstufft> I'll probably use it in Warehouse at the very least, might propose using it in pip

[16:43:05] <dstufft> I was going to submit a PR to distlib but the code made my brain hurt

[16:44:28] <dstufft> also I have a sneaking suspicion that distlib.version is wrong, but I wanted a fresh test suite to verify that it was, and to do that I needed to fully grok all of PEP440, and implementing it was a rasonable way of doing that

[17:13:06] <qwcode> dstufft, finding all the metadata-formats commits and conversation now in my ultra-generic "bitbucket" tag...

[17:13:52] <dstufft> qwcode: lol

[17:14:09] <dstufft> not like anything important happens on bitbucket ;)

[17:32:09] <jimbaker> dstufft, i have to a look at your thoughts here

[17:32:58] <dstufft> jimbaker: ah, I was using you as a convenient example :)

[17:57:47] <jimbaker> dstufft, :)