pmxbot IRC Log Viewer

[00:04:59] <buck1> hello friend

[00:05:31] <buck1> tdsmith: i might ask that on #python, you'll get 100x more eyes

[00:05:55] <buck1> i think nobody's home at the moment in #pypa

[00:06:11] <tdsmith> i'm patient :)

[00:06:20] <tdsmith> but thanks

[00:06:20] <buck1> just my two cents ;)

[00:09:55] <dstufft> tdsmith: I think that UCS2 vs UCS4 is binary incompatible

[00:10:39] <buck1> dstufft: https://github.com/pypa/pip/pull/2045#issuecomment-55979220

[00:12:07] <buck1> dstufft: dev became dev_r0

[00:12:21] <dstufft> strange

[00:12:24] <dstufft> i'd just ignore it personally

[00:12:27] <buck1> disabling the svn-tag option made it go away, but I dont have a clue why nobody else would see the issue

[00:12:30] <dstufft> unless it fails on travis

[00:12:46] <dstufft> pip's test suite is super dependent on the environment it's being run in unfortinately :(

[00:13:01] <dstufft> the dev vs dev-r0 comes from setuptools

[00:13:04] <buck1> dstufft: does my patch seem valid?

[00:13:11] <buck1> or is that a test scenario

[00:13:14] <tdsmith> dstufft: binary incompatibility would make the interpreter catch fire immediately, right?

[00:13:48] <dstufft> buck1: I don't think we're explicitly testing that thing (infact I have a PoC PR right now that just removes that setup.cfg file all together)

[00:13:52] <dstufft> tdsmith: unsure

[00:14:08] <dstufft> it's C, so it's probably undefined

[00:14:13] <buck1> dstufft: merge my PR then, and call it fair?

[00:14:33] <buck1> i'd be nervous to just ignore the test, i want coverage for my chagne

[00:15:10] <dstufft> buck1: just delete that whole line instead of commenting it out

[00:15:25] <buck1> derp. that's what i meant to do. amending

[00:17:21] <buck1> amended, CI running.

[00:20:06] <buck1> dstufft: does this change seem right/wrong? https://github.com/pypa/pip/pull/2033/files

[00:20:33] <buck1> it's either an impossible case or missing test coverage, but i can't tell which

[00:21:55] <dstufft> missing coverage I think

[00:22:03] <dstufft> or rather

[00:22:11] <dstufft> I think it's a case that's technically possible

[00:22:16] <dstufft> but is likely an edge case

[00:22:28] <buck1> i'll try to add coverage in that case

[00:22:40] <buck1> i'm trying to touch that function, but the number of cases is freaking me out

[00:22:43] <buck1> states

[00:22:57] <dstufft> yea, pip isn't well factored

[00:23:06] <dstufft> it's slowly getting better

[00:23:09] <buck1> dstufft: do you have any thoughts about how it might be refactored?

[00:23:14] <buck1> i have cycles this week to spend

[00:23:33] <dstufft> part of that has been deprecating/removing stuff so that we can lower the number of things it has to support

[00:23:37] <dstufft> buck1: sec gotta afk

[00:23:43] <buck1> np

[00:24:04] <buck1> dstufft: i saw you were unable to remove the dependency-links stuff, sad

[00:26:06] <buck1> i've poured over the thing for a few hours and it feels like there's a couple types that could be created to help contain the complexity

[00:26:39] <buck1> without domain expertise i'd be trying pretty randoms stuff till it looked ok

[00:27:47] <dstufft> buck1: it'll get removed eventually, we could have left it out but it was leaving too many people in a lurch for now

[00:28:01] <buck1> i saw

[00:28:06] <dstufft> buck1: I don't have any immediate thoughts, mostly i've been trying to simplify the number of cases it needs to handle first

[00:28:46] <buck1> basically they're putting data in setup.py that would normally live in a registry

[00:28:49] <buck1> from what i read

[00:29:39] <dstufft> yea

[00:29:55] <dstufft> there's not a particularly good argument for having it on stuff on PyPI

[00:30:11] <dstufft> but for companies who are doing things internally it can be powerful for deploys from github kind of thing

[00:30:25] <buck1> we have an internal pypi server

[00:30:43] <buck1> what i understood is that they dont want to cut a release for dev versions that might not actually make the cut

[00:31:05] <buck1> we haven't gotten that far along in our packaging story to need that yet

[00:31:19] <buck1> we sometimes put git+ urls in our requirements.txt tho

[00:31:30] <dstufft> buck1: besides removing stuff, I've also been trying to build lower level primtiives to replace some of the older stuff, like PEP 440 and the like, and I've been planing on working my way up the stack from low level pieces to higher level parts, if you want to tackle it before I get to it you're more than welcome too do that though :)

[00:31:51] <buck1> i'm not familiar with 440

[00:32:27] <dstufft> a versioning standard

[00:32:30] <buck1> dstufft: do you remember my problem statement?

[00:32:48] <dstufft> buck1: I don't sorry :(

[00:33:04] <buck1> no worries! perormance optimization for == reqs

[00:33:11] <buck1> don't go to http if satisfied by files

[00:33:46] <buck1> requires rearranging find_requirement to the best of my understanding

[00:34:33] <buck1> it currently lumps file:// and http:// together into 'urls'

[00:37:57] <buck1> find_requirement has 29 local vars

[00:38:04] <buck1> 30 branches

[00:38:09] <buck1> 82 statements

[00:39:41] <dstufft> lol

[00:39:51] <dstufft> buck1: Ok, that reminds me of a simplification I wanted to make too

[00:39:55] <dstufft> gonna post on distutils-sig

[00:40:23] <buck1> i see several phases in there, and some general flows that are repeated for four classes of location

[00:40:37] <buck1> i might make a locations class to encapsulate a bit?

[00:40:41] <buck1> dont know.

[00:42:26] <dstufft> buck1: oh, I do know one thing I was thinking about, different types of Finders that you can compose together

[00:42:38] <buck1> do tell

[00:42:39] <dstufft> a SimpleIndexFinder, FileLocationFinder, FindLinksFinder

[00:42:56] <buck1> if you make a sketch i'll look at implementation

[00:43:12] <buck1> pseudocode in a pastebin, whatever's simplest

[00:46:47] <dstufft> buck1: no real code here, but https://bpaste.net/show/205ce2f8fda9

[00:47:01] <buck1> that's a fair sketch

[00:47:25] <dstufft> I have no idea if that's a good idea or if it'll work well or not, but it's one thing I've thought about before

[00:47:36] <buck1> i'll look at it more closely

[00:47:47] <dstufft> each individual class should be a lot easier to test, sicne it only has to handle one type of discovery

[00:47:51] <buck1> i see a couple of these methods are begging for @cached_property

[00:49:47] <buck1> https://pypi.python.org/pypi/cached-property

[01:05:18] <dstufft> buck1: https://mail.python.org/pipermail/distutils-sig/2014-September/024820.html thing to remove some of the cases that PackageFinder has to handle

[01:05:39] <buck1> that's from tomorrow

[01:05:42] <buck1> time traveller

[01:07:12] <buck1> what is bandersnatch

[01:07:23] <Alex_Gaynor> a popular pypi mirroring tool

[01:07:31] <buck1> ah we should look at that

[01:07:45] <buck1> Alex_Gaynor: do you know, can i give it a whitelist of things to mirror?

[01:07:58] <Alex_Gaynor> I haven't ever used it myself

[01:11:18] <dstufft> there's no white listing of things to mirror

[01:11:21] <dstufft> it's a full mirror

[01:11:29] <dstufft> there is devpi which will do on demand mirroring

[01:11:42] <buck1> that one doesn't have a whitelist as well pretty sure

[01:11:49] <dstufft> e.g. it won't actually mirror anything, but it'll pretend it has, until you do ``pip install requests``, at which point it'll start mirroring requests

[01:12:02] <buck1> our compromise with legal is that we'll eval any new packages at least once

[01:12:06] <dstufft> ah

[01:12:10] <dstufft> yea I don't think it'll do that

[01:12:18] <dstufft> they might accept that feature though

[01:12:32] <buck1> yea i just want the work to have been done for me :)

[01:12:37] <buck1> as so often happens with python

[01:13:19] <buck1> dstufft: would your modification to the search eliminate the else I pointed out?

[01:13:32] <dstufft> no

[01:13:41] <dstufft> it'd elimate some other oens tho

[01:13:42] <buck1> ok i'll file a ticket against myself for coverage

[01:13:48] <dstufft> I'm making a quick PR actually for a PoC

[01:13:48] <buck1> do it tomorrow

[01:13:53] <buck1> woo

[01:14:18] <buck1> dstufft: how do you feel about my adding a pylintrc to the project

[01:14:29] <buck1> not automatically used as yet

[01:14:34] <buck1> but good for those that opt in

[01:14:35] <dstufft> what's wrong with flake8

[01:14:42] <buck1> i use both in tandem

[01:14:47] <buck1> it's more sensitive

[01:15:03] <buck1> such as: no such value in that module

[01:15:14] <buck1> : value defined outside of __init__

[01:15:17] <buck1> etc

[01:16:03] <buck1> i've done some lint cleanup to pip.index, and want to know if i should put the pylintrc in the same PR or not

[01:16:11] <Alex_Gaynor> I'm not a big fan of pylint, mostly because when I run it against extremely well tested and tended projects it still whines about tons of random stuff

[01:16:20] <Alex_Gaynor> e.g. it seems to think every single function should have a docstring

[01:16:23] <buck1> it needs tuned

[01:16:27] <buck1> i turn that one off always

[01:16:32] <buck1> thus the pylintrc

[01:16:52] <Alex_Gaynor> it's also mad that my class has too few public methods

[01:16:57] <buck1> would maybe make it usable for you

[01:17:05] <buck1> i also always modify min-methods to 0

[01:17:08] <buck1> also in the pylintrc

[01:17:25] <buck1> but there's a lot of baby in that bathwater imo

[01:17:39] <dstufft> I'd probably not want to add it personally unless we were using it in the test suite or something. Major problem I have with adding it though, is it creates the appearance that those are the rules that the pip project expects people to follow

[01:17:43] <buck1> Alex_Gaynor: my pylintrc might make it usable for you

[01:17:52] <buck1> dstufft: ah k

[01:17:58] <Alex_Gaynor> *shrug* I'm not really into linting tools that you have to super customize

[01:18:00] <buck1> somewhere out of the way to stuff it?

[01:18:11] <buck1> or i'll just keep it in my homedir..

[01:18:40] <dstufft> buck1: you could always just put it in your checkout and add it to .git/info/exclude

[01:18:46] <buck1> Alex_Gaynor: also linters arn't for superhumans

[01:18:58] <dstufft> which will act like it was added to .gitignore except without having to commit it

[01:19:02] <buck1> dstufft: i work on several machines tho

[01:19:07] <buck1> wev.

[01:47:08] <buck1> uuuggghhhh deadlocked again i think

[01:51:05] <dstufft> buck1: unless you can repro it I wouldn't worry about it, our subshells to git/hg/svn sometimes spin forever

[01:51:23] <buck1> reproed three times >.<

[01:51:28] <buck1> doing the faulthandler trick again

[01:51:37] <dstufft> :[[[[

[02:33:27] <buck1> dstufft: looks like it's stuck on bitbucket, I think http://paste.pound-python.org/show/sDtBbvhoD45KF9royuw6/

[02:33:47] <buck1> although i dont see why there's three eval iter's below the select

[02:36:08] <dstufft> bitbucket could be acting up

[11:50:44] <jhermann> hi, can i assume that pip develop branch can handle unicode when writing to --log-file? 1.5.6 can not.

[12:31:41] <dstufft> jhermann: it should be able to.

[16:34:42] <jhermann> can do a PR if you think it's worthwhile

[16:35:21] <dstufft> the enxt release is hopefully in the near future, we don't plan to do another 1.5.x, and we've ripped out the custom logging code and replaced it with the stdlib logging in the next release

[16:35:29] <dstufft> so hopefully it should wall work now

[16:37:42] <dstufft> jhermann: you might try using the develop branch and seeing if it works for you

[16:37:45] <dstufft> that would be good information

[17:11:21] <buck11> any idea what causes this? http://paste.pound-python.org/show/taOL6QhXTHS6iRxBN3sX/

[17:12:03] <buck11> !logs

[17:12:03] <pmxbot> http://chat-logs.dcpython.org/channel/pypa

[17:21:23] <dstufft> buck11: never seen it before, looks like it's certainly a problem with some of our code in tests/conftest.py tho

[17:21:45] <buck11> thanks

[17:22:00] <buck11> this test suite seems to have a mind of its own

[17:22:52] <buck11> can you exorcise a code base?

[17:24:48] <dstufft> ha

[17:24:56] <dstufft> the pip test suite is not good

[17:25:01] <dstufft> it's gotten better over time

[17:25:16] <buck11> git clean --ffdx made it go away

[17:25:23] <buck11> maybe it saw one of my little tmp files

[17:25:49] <buck11> it's a rough situation because it's inherently no good to just-unit test this thing

[17:26:17] <buck11> i dont think it's a situation we've generally solve in software

[17:26:25] <buck11> testing systems that inherently talk to other systems

[17:32:39] <buck11> how come version-check went away? just curious

[17:35:05] <buck11> err... you added that. nvm.

[18:00:17] <buck11> dstufft: I'd like to add a @cached_property utility to pip

[18:00:29] <buck11> i could either add a dependency, or put a tiny utility module somewhere

[18:00:56] <dstufft> probably best to put it in pip/utils/__init__.py

[18:01:02] <buck11> kk

[19:54:06] <buck1> !log

[19:54:18] <buck1> !logs

[19:54:18] <pmxbot> http://chat-logs.dcpython.org/channel/pypa

[21:38:49] <buck1> dstufft: what's the case that gives url_name is None here? https://github.com/pypa/pip/pull/2033/files#diff-a1f863caafabb33c2e33facb84c28dbfR251

[21:39:02] <buck1> seems like req.url_name would need to be none

[21:40:57] <Alex_Gaynor> dstufft: btw, did you see my PR to pypi?

[21:46:54] <dstufft> buck1: I'm not sure offhand

[21:46:56] <dstufft> Alex_Gaynor: nope!

[21:47:13] <Alex_Gaynor> dstufft: right now trying to log in with a password that contains a colon explodes, lol

[21:47:20] <Alex_Gaynor> dstufft: https://bitbucket.org/pypa/pypi/pull-request/50/dont-explode-on-passwords-with-colons/diff

[21:47:21] <dstufft> oh

[21:47:28] <dstufft> maybe people should have weaker passwords!!

[21:47:30] <buck1> xafer: i'd rather not diverge from bottle, but it's a simple change i could make

[21:47:30] <buck1> xafer: you choose

[21:47:31] <buck1> dstufft: rgr, i'll figure it out

[21:47:46] <buck1> pypi doesn't support emoji in my password :(

[21:47:50] <Alex_Gaynor> dstufft: I'll let them know ;-)

[21:47:58] <buck1> jk i haven't tried -X

[21:48:11] <Alex_Gaynor> dstufft: danke

[21:48:20] <dstufft> that should deploy to testpypi in 15 minutes or so

[21:49:00] <xafer> buck1, yes and https://github.com/pydanny/cached-property/blob/master/cached_property.py did the same :)

[21:49:17] <buck1> nearly sure he got it from the same place

[21:49:24] <buck1> err it's documented there

[21:49:26] <buck1> he did.

[21:49:45] <buck1> xafer: so, issue dropped/

[21:50:05] <xafer> so I'm wondering if there is a good reason behind or if everybody is copy-pasting the same recipe :p

[21:50:23] <buck1> less painful than dependencies =X

[21:50:53] <Alex_Gaynor> I can tell you exactly where I was when I added that code to Django.

[21:51:17] <buck1> Alex_Gaynor: and did you write it from scratch?

[21:51:43] <Alex_Gaynor> Yes. I was sitting next to Armin Ronacher though, I don't remember if he mentioned the code was in werkzeug or not.

[21:52:07] <buck1> xafer: https://docs.djangoproject.com/en/1.6/_modules/django/utils/functional/#cached_property

[21:52:28] <xafer> yes see it ^^

[21:53:03] <buck1> the werkzeug source isn't so nicely linked

[21:53:27] <buck1> xafer: https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/utils.py#L35

[21:54:32] <xafer> but is there a good reason to change and access __dict__ instead of a cleaner setattr ?

[21:55:01] <buck1> i gave one, weak reason

[21:56:02] <xafer> the consistency with bottle, werkzeug, django and cached_property ?

[21:56:36] <buck1> i'd personally rather not find out the hard way. I've seen it written like this by ~3 other people as well

[21:56:51] <buck1> i meant beyond those

[21:57:22] <buck1> .. should probably be stdlib at this point

[21:57:58] <tos9> buck1: You can't setattr.

[21:58:05] <tos9> The whole point is to evade the descriptor protocol.

[21:58:15] <buck1> tos9: it worked in my little test

[21:59:53] <buck1> dstufft: the case stems from InstallRequirement.req is None

[22:00:15] <xafer> tos9, worked in my test also

[22:00:41] <buck1> i started to say that too, but realized i might be wrong

[22:00:43] <buck1> and i was

[22:02:41] <tos9> buck1: "works" dpends on what you tried -- the thing is supposed to make the property disappear

[22:03:06] <tos9> if your class has a __setattr__ that does os.system("rm -rf"), __dict__ won't invoke it, setattr will

[22:03:07] <buck1> and it does. show the code that doesn't work.

[22:03:16] <buck1> sure.

[22:03:23] <tos9> I guess I said "descriptor protocol" when I meant "it's not meant to call setattr"

[22:03:41] <buck1> it would be surprising to call setattr there i suppose

[22:03:48] <buck1> similar to what i said in review

[22:03:56] <buck1> __setattr__ *

[22:07:22] <buck1> dstufft: so i've pinned down the missing coverage to no paths/urls in unit.test_finder

[22:16:11] <buck1> what's the most-vanilla test case package

[22:18:10] <tomprince> unittest?

[22:19:28] <buck1> i choose you, FSPkg

[22:27:41] <buck1> ... is it possible that the pip install ./that/package case is wholly broken in develop branch?

[22:28:14] <buck1> no, it seems to work

[22:30:16] <buck1> that scenario doesn't pass through PackageFinder.find_requirement

[22:30:29] <buck1> dstufft: i believe i've shown that its' in impossible case

[22:30:41] <buck1> going to reopen my PR and show my results

[22:30:48] <buck1> it's an*

[22:35:03] <buck1> xafer: re-open this for me? https://github.com/pypa/pip/pull/2033

[22:36:52] <xafer> buck1, sorry dont have the credentials ^^

[22:37:20] <buck1> thanks anyway tho

[22:38:40] <xafer> and going to sleep now :) bye

Log file Viewer

Help | Karma | Search:

#pypa logs for Thursday the 18th of September, 2014