-
Notifications
You must be signed in to change notification settings - Fork 3
feat: initial oas generators support; algod http clients with tests covering transaction endpoints; refinements in python ffi package #63
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
base: main
Are you sure you want to change the base?
Conversation
…uto generate valid baseline tests
…dify - Instead setting up a structure for custom mustache files implementing manually written tests given that each end point (total around 55) often requires complex state setup - For the time being the only test established is the test for sending raw transactions
Refines the algokit-transact Python package to improve compatibility with Poetry and Python 3.13. Updates dependencies and build configurations for a smoother development experience.
f858c9a
to
97af59d
Compare
97af59d
to
49cf4e5
Compare
Haven't reviewed in-depth yet, but would it be possible make the Python changes in a separate PR? We have merge conflicts anyways after #61 and having that work in a separate PR will make it a bit easier to review and iterate. |
b79287d
to
8e6f806
Compare
8e6f806
to
6b060a0
Compare
Could we add extension to the moustache template files to make them a bit easier to digest? For example, instead of |
], | ||
"scripts": { | ||
"test": "vitest", | ||
"build": "npm run clean && npm run build:esm && npm run build:cjs", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hey @aorumbayev, sorry I missed this in my first round of review. Do you think that we should change this to bun instead of npm to align with the rest of the code base?
Proposed changes
This PR introduces the infrastructure for generating Algorand API clients using the OpenAPI Generator tool. This approach automates the creation of clients in various languages (initially focusing on Python and TypeScript for
algokit-utils
) from a single OpenAPI specification, ensuring consistency and reducing maintenance overhead.Motivation:
As outlined in
docs/research/openapi-generators.md
, manually maintaining API clients across multiple languages is time-consuming and error-prone. Using OpenAPI generators allows us to:Changes:
/api
to support the generation process:api/specs/
: Contains the OpenAPI specifications (v2 and v3).api/api_clients/
: Will hold the generated client code.api/oas_templates/
: Stores custom Mustache templates for tailoring generated code.api/scripts/
: Includes utility scripts (generate-api-clients.ts
) for managing the generation process.openapitools.json
,package.json
,tsconfig.json
,openapi-config.yaml
) to configure the generator and manage dependencies (likebun
for running the generation script).AvmValue
schema for Python).scripts/generate-api-clients.ts
(run viabun run
) to orchestrate the client generation, including handling.openapi-generator-ignore
files to protect custom code.get pending txns
,get tx params
,post raw txn
) needed foralgokit-utils
integration.docs/research/openapi-generators.md
detailing the approach, structure, rationale, and future work.poetry.lock
andpyproject.toml
inpackages/python/algokit_transact
reflecting changes potentially related to CFFI or other dependencies needed for the generated clients or testing infrastructure. (Specific updates includecffi
,maturin
,packaging
,pluggy
,pytest
,tomli
, and adjustments to dev dependencies).This PR lays the baseline for a more scalable and maintainable approach to managing Algorand API clients across different languages within the monorepo project.