You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Note: this is the fork of openapi-python-client maintained and used by Benchling.
2
2
3
-
- Report bugs via [issues](https://github.com/openapi-generators/openapi-python-client/issues)
4
-
- Request features via [discussions](https://github.com/openapi-generators/openapi-python-client/discussions)
5
-
- Contribute code via [pull request](https://github.com/openapi-generators/openapi-python-client/pulls)
3
+
If you want the official package, go to the upstream repository: https://github.com/openapi-generators/openapi-python-client
6
4
7
-
## Reporting a bug
5
+
For contribution guidelines (including contributing fixes from our fork to the upstream repo), see Benchling internal documentation.
8
6
9
-
A bug is one of:
7
+
This document mostly contains basic developer instructions.
10
8
11
-
1. You get an exception when running the generator
12
-
2. The generated code is invalid or incorrect
13
-
3. An error message is unclear or incorrect
14
-
4. Something which used to work no longer works, except:
15
-
1. Intentional breaking changes, which are documented in the [changelog](https://github.com/openapi-generators/openapi-python-client/blob/main/CHANGELOG.md)
16
-
2. Breaking changes to unstable features, like custom templates
9
+
## Setting up environment
17
10
18
-
If your issue does not fall under one of the above, it is not a bug; check out "[Requesting a feature](#requesting-a-feature).
11
+
Create a virtualenv with the lowest compatible Python version (currently 3.9).
19
12
20
-
### Report requirements
13
+
To install dependencies:
21
14
22
-
A bug report **must** have an OpenAPI document that can be used to replicate the bug. Reports without a valid document will be closed.
15
+
```
16
+
pip install poetry
17
+
poetry install
18
+
```
23
19
24
-
## Requesting a feature
20
+
## Running tests
25
21
26
-
A feature is usually:
22
+
See the [upstream repo]() for a full description of how the tests in this project are written.
27
23
28
-
1. An improvement to the way the generated code works
29
-
2. A feature of the generator itself which makes its use easier (e.g., a new config option)
30
-
3.**Support for part of the OpenAPI spec**; this generator _does not yet_ support every OpenAPI feature, these missing features **are not bugs**.
24
+
`poetry run task unit` runs only the basic unit tests.
31
25
32
-
To request a feature:
26
+
`poetry run task test` runs unit tests plus end-to-end tests.
33
27
34
-
1. Search through [discussions](https://github.com/openapi-generators/openapi-python-client/discussions/categories/feature-request) to see if the feature you want has already been requested. If it has:
35
-
1. Upvote it with the little arrow on the original post. This enables code contributors to prioritize the most-demanded features.
36
-
2. Optionally leave a comment describing why _you_ want the feature, if no existing thread already covers your use-case
37
-
2. If a relevant discussion does not already exist, create a new one. If you are not requesting support for part of the OpenAPI spec, **you must** describe _why_ you want the feature. What real-world use-case does it improve? For example, "raise exceptions for invalid responses" might have a description of "it's not worth the effort to check every error case by hand for the one-off scripts I'm writing".
28
+
## Linting/type-checking
38
29
39
-
## Contributing Code
30
+
The project uses ruff. `poetry run task lint` and `poetry run task format` run `ruff check` and `ruff format`.
31
+
32
+
`poetry run task mypy` runs `mypy` on only the package module (tests are excluded).
40
33
41
-
### Setting up a Dev Environment
34
+
`poetry run task check` runs all of those plus tests.
42
35
43
-
1. Make sure you have [PDM](https://pdm-project.org) installed and up to date.
44
-
2. Make sure you have a supported Python version (e.g. 3.8) installed.
45
-
3. Use `pdm install` in the project directory to create a virtual environment with the relevant dependencies.
36
+
## Contributing Code
37
+
38
+
This section is a copy from the upstream repo, with some changes due to Benchling test framework additions that haven't yet been accepted upstream.
46
39
47
40
### Writing tests
48
41
@@ -61,7 +54,7 @@ This project aims to have all "happy paths" (types of code which _can_ be genera
61
54
62
55
Snapshot tests verify that the generated code is identical to a previously-committed set of snapshots (called a "golden record" here). They are basically regression tests to catch any unintended changes in the generator output.
63
56
64
-
In order to check code changes against the previous set of snapshots (called a "golden record" here), you can run `pdm e2e`. To regenerate the snapshots, run `pdm regen`.
57
+
In order to check code changes against the previous set of snapshots (called a "golden record" here), you can run `poetry run task e2e`. To regenerate the snapshots, run `poetry run task regen`.
65
58
66
59
There are 4 types of snapshots generated right now, you may have to update only some or all of these depending on the changes you're making. Within the `end_to_end_tests` directory:
67
60
@@ -84,15 +77,3 @@ These include:
84
77
85
78
* Regular unit tests of basic pieces of fairly self-contained low-level functionality, such as helper functions. These are implemented in the `tests` directory, using the `pytest` framework.
86
79
* Older-style unit tests of low-level functions like `property_from_data` that have complex behavior. These are brittle and difficult to maintain, and should not be used going forward. Instead, they should be migrated to functional tests.
87
-
88
-
### Creating a Pull Request
89
-
90
-
Once you've written the tests and code and run the checks, the next step is to create a pull request against the `main` branch of this repository. This repository uses [Knope] to auto-generate release notes and version numbers. This can either be done by setting the title of the PR to a [conventional commit] (for simple changes) or by adding [changesets]. If the changes are not documented yet, a check will fail on GitHub. The details of this check will have suggestions for documenting the change (including an example change file for changesets).
91
-
92
-
### Wait for Review
93
-
94
-
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 we'll do our best to accommodate.
0 commit comments