Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add verify named argument to to_records #282

Closed
wants to merge 3 commits into from
Closed

Add verify named argument to to_records #282

wants to merge 3 commits into from

Conversation

j-wags
Copy link
Member

@j-wags j-wags commented Jun 15, 2024

Todos

Status

  • Ready to go

@ntBre
Copy link
Contributor

ntBre commented Jun 18, 2024

What do you think about generalizing this to **client_kwargs or something similar? In messing with the caching section of the retrieving_results example, I think providing the cache_dir kwarg to PortalClient automates caching throughout qcsubmit. If you could pass this through to_records that would speed up those calls too!

I also noticed that OptimizationResultCollection.to_basic_result_collection, for example, calls to_records internally, so any kwargs (verify or the ** version) probably need to be propagated anywhere to_records is called.

@ntBre
Copy link
Contributor

ntBre commented Jun 18, 2024

I might be getting ahead of myself, but if we decide to support these additional keywords, it might make more sense to have some kind of default_portal_client function that we call instead of PortalClient directly. That way the user can just override that function, and we don't have to worry about propagating kwargs through a huge fraction of the code base. Something like this?

from openff.qcsubmit import default_portal_client
from qcportal import PortalClient

def my_portal_client(addr):
    return PortalClient(addr, verify=False, cache_dir=".")

default_portal_client = my_portal_client

@j-wags
Copy link
Member Author

j-wags commented Jun 19, 2024

Oh, I really like the client_kwargs idea, and good catch noticing to_records is called in more places internally. I need to think a little more about how to handle that.

The default_portal_client idea goes in the right direction - if we don't want to thread kwargs through everywhere we'll need to modify some sort of global state. But from what I recall, wrangling global state is a big pain. If we go this direction it might be best to offer users something like a context manager to give them a better handle on things.

@ntBre ntBre mentioned this pull request Jun 21, 2024
6 tasks
@j-wags
Copy link
Member Author

j-wags commented Jul 8, 2024

Superseded by #284

@j-wags j-wags closed this Jul 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add verify=False as an optional named argument to collection.to_records()
2 participants