- Document bugs and missing features as issues.
- Find and document the relevant OpenAPI specification for open issues.
- Create a pull request addressing an open issue.
- Make sure you have Poetry installed and up to date.
- Make sure you have a supported Python version (e.g. 3.8) installed and accessible to Poetry (e.g. with pyenv.
- Use
poetry install
in the project directory to create a virtual environment with the relevant dependencies. - Enter a
poetry shell
to make running commands easier.
- Write some code and make sure it's covered by unit tests. All unit tests are in the
tests
directory and the file structure should mirror the structure of the source code in theopenapi_python_client
directory. - When in a Poetry shell (
poetry shell
) runtask check
in order to run most of the same checks CI runs. This will auto-reformat the code, check type annotations, run unit tests, check code coverage, and lint the code. - If you're writing a new feature, try to add it to the end to end test.
- If adding support for a new OpenAPI feature, add it somewhere in
end_to_end_tests/openapi.json
- Regenerate the "golden record" with
task regen
. This is a client generated from the OpenAPI document used for end to end testing. - Check the changes to
end_to_end_tests/golden-record
to confirm only what you intended to change did change and that the changes look correct.
- If adding support for a new OpenAPI feature, add it somewhere in
- Run the end to end tests with
task e2e
. This will generate a client againstend_to_end_tests/openapi.json
and compare it withend_to_end_tests/golden-record
. The test will fail if anything is different. The end to end test is not included intask check
as it takes longer to run and doesn't provide very useful feedback in the event of failure. If this test does fail, the easiest way to check what's wrong is to runtask regen
and check the diff ofgolden-record
. - Include a summary of your changes in
CHANGELOG.md
. If there isn't an "Unreleased" version in the CHANGELOG yet, go ahead and add one.
Once you've written the code and run the checks, the next step is to create a pull request against the main
branch of this repository. Currently @dbanty is the
only reviewer / approver of pull requests for this repo, so you should @mention him to make sure he sees it. Once your PR is created, a series of automated checks
should run. If any of them fail, try your best to fix them. Note that currently deepsource tends to find "issues" that aren't actually issues, so there might be
failures that don't have anything to do with the code you changed. If that's the case, feel free to ignore them.
As soon as possible, your PR will be reviewed. If there are any changes requested there will likely be a bit of back and forth. Once this process is done, your changes will be merged into main and included in the next release. If you need your changes available on PyPI by a certain time, please mention it in the PR and I'll do my best to accomodate.