PMXBOT Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Tuesday the 7th of May, 2019

(Back to #pypa-dev overview) (Back to channel listing) (Animate logs)
[00:35:36] <sumanah> pradyunsg: I've created a few pip issues with documentation that are good first issues.
[11:10:57] <arti> !logs
[11:10:57] <pmxbot> http://kafka.dcpython.org/channel/pypa-dev
[11:40:56] <arti> Hi, how do i test 2FA on test.pypi.org?
[13:17:54] <cooperlees> dstufft: All good :)
[16:08:27] <woodruffw> arti: i *believe* 2FA has been enabled for everybody on test.pypi, you should see it at the bottom of the account management page
[16:34:34] <dstufft> woodruffw: it hasn't yet I don't think, let m get that done though.
[16:35:09] <dstufft> woodruffw: nvm it was done!
[16:35:27] <woodruffw> woohoo
[20:46:00] <sumanah> dstufft: hey, so one name we had at Wikimedia was "Bug Wrangler"
[20:46:15] <sumanah> similarly at Archive of Our Own we have "Tag Wranglers"
[20:46:20] <sumanah> how about "wrangler"?
[20:46:26] <sumanah> or "ranger"
[20:46:45] <sumanah> ranging through the project, keeping an eye on things and sorting stuff out
[20:46:49] <sumanah> "Sorter"?
[20:46:50] <dstufft> works for me, the only thing I thought of was like, gardener
[20:46:55] <sumanah> I like "gardener"
[20:47:18] <dstufft> alright, w'ell go with that
[20:49:04] <dstufft> https://s.caremad.io/EwAMMdhdzOw0Shz/ lol
[20:49:59] <dstufft> sumanah: I made you maintainer of that team, so you can add new people to it (though you can't, as I udnerstand it, add new people to the org)
[20:50:16] <dstufft> Gonna send an email out about it
[20:50:18] <sumanah> nod nod nod
[20:50:19] <sumanah> thanks dstufft
[20:50:23] <dstufft> or actually gonna post on discourse
[20:50:26] <sumanah> dstufft: you feelin' better?
[20:50:42] <dstufft> my blood is staying inside my body where it belongs, so that's a positive
[20:51:02] <sumanah> I am in favor of reasonable boundaries being respected, yes
[20:54:08] <sumanah> separate note: anyone testing 2-factor auth on Test PyPI: we have just discovered that right now new Test PyPI accounts (as in, created since sometime yesterday) do not have the flag set so they don't see 2FA in their account settings.
[20:55:21] <sumanah> I'd like us to run the "turn this on for everybody" action again just to get that taken care of, then figure out what to do next
[20:56:14] <sumanah> I think di_codes told me that turning it on by default for all Test PyPI accounts would also turn it on for all canon PyPI accounts (does this mean we ought to have a better feature flag system in general, or just for this feature?)
[20:56:50] <sumanah> (and I presume that constraint would also stop us from doing something to fix this like: verifying the email address triggers turning on 2FA support)
[20:58:16] <dstufft> sumanah: https://discuss.python.org/t/pypa-gardeners/1626
[20:58:34] <dstufft> as it is turning it on for everyone owuld turn it on for all PyPI accounts, but we could tweak that
[20:58:46] <dstufft> and we don't really have a good feature flag system, we should but we don't
[20:59:55] <sumanah> dstufft: for now can you re-run the SQL to turn it on for all Test PyPI accounts? or am I misunderstanding?
[21:12:15] <honzakral> di_codes: ping
[21:17:49] <dstufft> sumanah: think Ernest has to do that
[21:28:00] <sumanah> EWDurbin: ^
[21:31:27] <dstufft> sumanah: do we know if "triage" permission allows transfering issues?
[21:32:14] <sumanah> dstufft: I don't see the word "transfer" in the thing the GitHub worker sent me, so I think it does not cover that
[21:32:50] <di_codes> honzakral: o/
[21:33:45] <dstufft> would be cool if it did, I think you gave me an email address somewhere I can email them at, but I'm not finding it in any of the comms we have, can you either resend that to me, or follow up with them that it would be great if it allowed that
[21:35:40] <sumanah> dstufft: lemme fwd
[21:36:02] <dstufft> sumanah: awesome, thanks
[21:36:05] <sumanah> :)
[21:37:34] <honzakral> di_codes: I am looking at https://github.com/elastic/elasticsearch-dsl-py/issues/1181 and I am a bit confused
[21:37:48] <honzakral> where is the code for `request.es.query`?
[21:38:58] <honzakral> di_codes: Q() is just a query which is just a part of the search request, the more important part, which is responsible for the response deserialization, is on the search object itself which is created by request.es which I cannot now find anywhere
[21:39:29] <honzakral> found it
[21:40:18] <dstufft> https://github.com/pypa/warehouse/blob/master/warehouse/search/__init__.py#L66-L77
[21:40:18] <dstufft> oh
[21:40:20] <dstufft> you found it
[21:45:16] <dstufft> sumanah: it occurs to me that I could make the argument that basically every committer to a PyPA project should be a gardener
[21:45:27] <dstufft> I'm not sure I believe that argument yet
[21:45:31] <dstufft> but I think I could make it
[21:45:32] <honzakral> I believe the problem is that I fixed #1091 on the dsl which makes the Document subclass associated with the first index it is called with and then subsequent search calls makes it so the Document doesn't recognize it should be used to deserialize a particular hit as that hit has different index
[21:46:22] <honzakral> proper solution would be to explicitly assign an index name (ideally a wildcard) with the Document by doing class Index: name = "index-to-be-used-*"
[21:46:41] <dstufft> honzakral: is that a change we need to make?
[21:47:06] <honzakral> yes, that should be on Project in packaging/search.py
[21:49:15] <honzakral> this is causing the issues: https://github.com/elastic/elasticsearch-dsl-py/blob/master/elasticsearch_dsl/document.py#L112-L114 - it is a callback that is called on the Document subclass (Project) to determine whether it should be used to deserialize a given result ( https://github.com/elastic/elasticsearch-dsl-py/blob/master/elasticsearch_dsl/search.py#L214-L217 )
[21:50:27] <dstufft> honzakral: do you think you'd be able to submit a PR for that? If not I'll try to get it done in a bit
[21:51:16] <honzakral> I can but don't have the bandwidth to do proper tests etc, my apologies (I am delivering a training today)
[21:51:56] <di_codes> honzakral: I can backfill the tests
[21:52:29] <honzakral> fwiw I'd also recommend using simple Project.search() instead of the whole es() function including get_index(). Will sketch it out in a branch
[21:52:36] <honzakral> di_codes: thank you, PR incoming!
[21:55:40] <dstufft> Did we get the TUF folks sorted out?
[21:56:47] <sumanah> dstufft: you mean did we talk with Lukas and Sebastian? yes, EWDurbin and pradyunsg talked with them today
[21:56:53] <dstufft> cool
[21:57:06] <honzakral> di_codes: https://github.com/pypa/warehouse/pull/5814
[21:58:09] <dstufft> oh interesting, that's not quite what I thought you mean, so I'm glad you were able to do a PR
[21:58:32] <di_codes> hmm, not what I was expecting. I have no idea how to actually test for this
[21:58:50] <di_codes> thanks honza!
[21:59:13] <dstufft> I'm not sure we have anything that can write tests for this currently
[21:59:40] <dstufft> I think it'd have to be either a integration test that stands up an ES instance and tries to query, or just manually test it
[22:04:05] <honzakral> btw ideally instead of the "*" you would have the prefix that all the project indices share ("projects-*" for example) for more explicit behavior. I have a comprehensive example how to make the entire workflow transparent in https://github.com/elastic/elasticsearch-dsl-py/blob/master/examples/alias_migration.py
[22:05:30] <honzakral> that way you can just use elasticsearch_dsl.connections.create_connection() to register a global es connection (instead of keeping track of it yourself) and just use Project.search() instead of the es() method