Design and roadmap¶

aioovh is developed in the open. This page states what it aims at, what it leaves out, and what comes next. Discussion happens in the GitLab issues.

Principles¶

Async only. No synchronous twin of the API: one way to do each thing.
Objects, not paths. The public surface follows what you manipulate; /me, /cloud/project and API versions are details of the routing.
Types first. If the type checker cannot follow it, it is not the API.
Everything reachable. Every operation OVHcloud publishes is either an object method or explicitly left to the raw layer.
Generated, then reviewed. The code is generated from the schemas the API serves; mapping.yaml places every API root in a business area, and the generator stops on a root it does not know or on a name clash.

Operations (aioovh._operations), private: one typed method per operation of each schema.
Objects (aioovh.billing, aioovh.compute...), public: business areas, collections, references and loaded objects, generated from the operations and mapping.yaml.

The architecture page details the mapping and how operations become objects.

A synchronous client.
Deprecated operations in the object layer: they stay reachable through ovh.raw.
Hiding the API: ovh.raw keeps the official package's get, post, put and delete on any path.

Step	Content
0.1	Every API as objects, collections, references, actions, bounded loading, typed errors, retries
0.2	`wait_until(...)` on tasks and services with a life cycle
0.3	References from fields that name another resource, plural names reviewed area by area
0.4	Documentation examples executed by the test suite, recipes for FastAPI and task workers
later	A shared core with aioscaleway, then other European providers

aioovh stands on what others built: the official OVHcloud package for the signature, the endpoints and the error names, the Stainless generated SDKs for the resource tree, hcloud-python for bound objects, and the Azure SDK design guidelines for versions and paging.