Actions
Idea #21283
closedMake Python arvados.api importable
Status:
Resolved
Priority:
Normal
Assigned To:
Category:
SDKs
Target version:
Start date:
12/11/2023
Due date:
Story points:
-
Release:
Release relationship:
Auto
Description
Steps to reproduce: import arvados.api
Expected result: I can now call functions in the arvados.api
module like arvados.api.api_client
, arvados.api.api_from_config
, etc.
Actual result: I can't do any of that, because arvados/__init__.py
shadows arvados.api
to be arvados.api.api
, making the rest of the module difficult to access.
Proposed solution: Arcane magicks
Updated by Brett Smith about 1 year ago
21283-callable-api-module @ 1372710a7f3b33d822c52455ed613c1063ad4b16 - developer-run-tests: #3956
- All agreed upon points are implemented / addressed.
- Yes
- Anything not implemented (discovered or discussed during work) has a follow-up story.
- N/A
- Code is tested and passing, both automated and manual, what manual testing was done is described
- See above
- Documentation has been updated.
- This change should be transparent to users, but I did take the opportunity to try to clarify the
arvados/__init__.py
docstring.
- This change should be transparent to users, but I did take the opportunity to try to clarify the
- Behaves appropriately at the intended scale (describe intended scale).
- The only scale change is adding another function to the call stack when constructing an Arvados API client, which should be an acceptable hit
- Considered backwards and forwards compatibility issues between client and server.
- The whole goal of this branch is to be transparent to normal API use. There are some ways to tell that something has changed through deep introspection. For example,
isinstance(arvados.api, types.ModuleType)
used to returnFalse
, and now it will returnTrue
. But I don't think we guarantee API compatibility at this level, just at the level of function signatures, which are all retained.
- The whole goal of this branch is to be transparent to normal API use. There are some ways to tell that something has changed through deep introspection. For example,
- Follows our coding standards and GUI style guidelines.
- Technically this bends PEP 8's "two blank lines after class definition" rule, but I think that's appropriate given that (a) it's short (b) it's used more as a one-shot class decorator than a normal class and (c) we have existing code that follows the same pattern.
Updated by Brett Smith about 1 year ago
- Status changed from In Progress to Resolved
Applied in changeset arvados|55f5776c23afcf47f7229e6547e6d5bae6f6c570.
Actions