feat: multipart upload opt in AR-6 #437
Conversation
Introduces a `multipart_uploads` boolean setting (default: true) that, when set to false, generates lighter base client variants that omit multipart/file-upload handling. Adds four new no-upload base client dependency files (async, sync, with/without OpenTelemetry) and a corresponding integration test fixture.
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
| async_client: bool = True, | ||
| base_client_name: str = "AsyncBaseClient", | ||
| base_client_file_path: str = DEFAULT_ASYNC_BASE_CLIENT_PATH.as_posix(), | ||
| base_client_module_name: str = "", |
There was a problem hiding this comment.
- This class provides the defaults for parameters to generate the functional default implementation (default async base client). Shouldn't this param be set then?
- What should be set here for using custom base client class?
There was a problem hiding this comment.
base_client_module_name is the name the base client is written under in the generated package (and what client.py imports). It has to stay because PackageGenerator needs that output name, and it can't be derived from base_client_file_path.stem: for the default no-upload variants the source file (async_base_client_no_upload.py) differs from the output module (async_base_client.py). Using the stem would give the wrong name.
So it's a computed value the generator consumes, not user config. I'd keep resolving it together with base_client_name / base_client_file_path in _set_default_base_client_data, since splitting it out produces the same value anyway and just adds a "default vs custom?" branch.
…led packages AR-3 (#439) Introduce a new `schema_paths` setting that builds the GraphQL schema from multiple sources. Each entry is resolved either as a dotted Python attribute path (e.g. `pkg.SCHEMA_DIR` or `pkg.get_schema_files`) - useful for pulling type definitions from installed packages - or as a local file/directory path. - schema.py: add `resolve_schema_paths` and `get_graphql_schema_from_paths` - main.py: wire `schema_paths` into both `client` and `graphqlschema` strategies - settings.py: add the `schema_paths` field and make the three schema sources (`schema_path`, `schema_paths`, `remote_schema_url`) mutually exclusive - providing more than one now raises InvalidConfiguration; simplify `using_remote_schema` accordingly - docs/README: document `schema_paths` and the mutual-exclusivity rule CI/CD does not pass. This is an unrelated error that is being fixed as part of [AR-6](#437) ## Acknowledgements While working on this, we noticed #431 by @esfomeado, which also tackled loading the schema from more than one source. After discussing it as a team, we went with a different approach - a dedicated `schema_paths` setting that additionally resolves dotted Python attribute paths from installed packages - which we felt fit the project better. Thanks @esfomeado for raising the problem and for your contribution! 🙏
Introduces a
multipart_uploadsboolean setting (default: true) that,when set to false, generates lighter base client variants that omit
multipart/file-upload handling. Adds four new no-upload base client
dependency files (async, sync, with/without OpenTelemetry) and a
corresponding integration test fixture.