[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.
[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: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)
[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: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: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: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