[amirabbas-jalali-bentley]

Description

The compute platform lists the tasks an organization can run at GET /compute/orgs/{org_id}/tasks, with each task's version, preview flag and the JSON Schemas of its parameters and results. The SDK had no way to read that list. This adds DiscoveryClient for it.

Changes

• DiscoveryClient (exported from evo.compute, with a from_context constructor) fetches every page of the listing with details=true and caches the combined catalogue for cache_ttl_seconds (300 by default). Concurrent calls on a cold cache share a single fetch.
• list_tasks, get_topics, get_topic_tasks and get_task read from that cache. Each takes force_refresh=True to fetch again straight away.
• Tasks are returned as TaskResource models, also exported. Fields the service adds later are kept rather than dropped.
• DiscoveryApi wraps the endpoint, including its topic, name, key, limit and offset filters. It is written by hand in the same style as the generated JobsApi and TasksApi.
• DiscoveryClient is added to the API client list for the docs.

from evo.compute import DiscoveryClient

discovery = DiscoveryClient.from_context(manager)

print(await discovery.get_topics())
for task in await discovery.get_topic_tasks("geostatistics"):
    print(task.name, task.version)

kriging = await discovery.get_task("geostatistics", "kriging")  # None if it isn't listed

No breaking changes; this only adds new classes.

Testing

• New tests run the client against a mocked discovery endpoint: the request it sends, parsing, pagination (including a page without a total), cache expiry, force_refresh, a single fetch for concurrent cold calls, the accessors and from_context.
• evo-compute tests: 516 passed (15 new). ruff check and ruff format --check are clean.

Checklist

• I have read the contributing guide and the code of conduct

[PaulCaygill-Seequent]

seems fine, can't see any issues with what you've done.

I don't really see why we need so many variations on the "get the response filtered this way", when a user could simply call list_tasks and then filter them themselves with some very simple python code. It's not technically a real issue, just an observation that we're making the client quite verbose - I think it's fine regardless

[aminabedi-bentley]

One minor comment and one major docs issue pointed out.
Otherwise LGTM!

[amirabbas-jalali-bentley]

seems fine, can't see any issues with what you've done.

I don't really see why we need so many variations on the "get the response filtered this way", when a user could simply call list_tasks and then filter them themselves with some very simple python code. It's not technically a real issue, just an observation that we're making the client quite verbose - I think it's fine regardless

Fair point. These are convenience methods for common lookups.
Callers can still use list_tasks and filter directly. I’ve kept them small, and they all share the same cached catalogue.