infra: Update version of the client to include updates BNCH-114718

.github/workflows/checks.yml

@@ -2,16 +2,16 @@ name: Run Checks
 
 on:
   push:
-    branches: [ "main" ]
+    branches: [ "prod/2.x" ]
   pull_request:
-    branches: [ "main" ]
+    branches: [ "prod/2.x" ]
   merge_group:
 
 jobs:
   test:
     strategy:
       matrix:
-        python: [ "3.8", "3.9", "3.10", "3.11", "3.12", "3.13" ]
+        python: [ "3.9", "3.10", "3.11", "3.12", "3.13" ]
         os: [ ubuntu-latest, macos-latest, windows-latest ]
     runs-on: ${{ matrix.os }}
     steps:
@@ -30,33 +30,33 @@ jobs:
         uses: actions/cache@v4
         with:
           path: .venv
-          key: ${{ runner.os }}-${{ steps.get_python_version.outputs.python_version }}-dependencies-${{ hashFiles('**/pdm.lock') }}
+          key: ${{ runner.os }}-${{ steps.get_python_version.outputs.python_version }}-dependencies-${{ hashFiles('**/poetry.lock') }}
           restore-keys: |
             ${{ runner.os }}-${{ steps.get_python_version.outputs.python_version }}-dependencies
-      - name: Install PDM
-        run: pip install pdm
+      - name: Install Poetry
+        run: pip install poetry
 
       - name: Install Dependencies
-        run: pdm install
+        run: poetry install
 
       - name: Check formatting
-        run: pdm run ruff format . --check
+        run: poetry run ruff format . --check
 
       - name: Run mypy
-        run: pdm mypy --show-error-codes
+        run: poetry run task mypy --show-error-codes
 
       - name: Lint
-        run: pdm run ruff check .
+        run: poetry run ruff check .
 
       - name: Run pytest without coverage
         if: matrix.os != 'ubuntu-latest'
-        run: pdm test
+        run: poetry run task test
         env:
           TASKIPY: true
 
       - name: Run pytest with coverage
         if: matrix.os == 'ubuntu-latest'
-        run: pdm test_with_coverage
+        run: poetry run task test_with_coverage
         env:
           TASKIPY: true
 
@@ -131,27 +131,31 @@ jobs:
       - name: Set up Python
         uses: actions/[email protected]
         with:
-          python-version: "3.8"
+          python-version: "3.9"
       - name: Get Python Version
         id: get_python_version
         run: echo "python_version=$(python --version)" >> $GITHUB_OUTPUT
       - name: Cache dependencies
         uses: actions/cache@v4
         with:
           path: .venv
-          key: ${{ runner.os }}-${{ steps.get_python_version.outputs.python_version }}-dependencies-${{ hashFiles('**/pdm.lock') }}
+          key: ${{ runner.os }}-${{ steps.get_python_version.outputs.python_version }}-dependencies-${{ hashFiles('**/poetry.lock') }}
           restore-keys: |
             ${{ runner.os }}-${{ steps.get_python_version.outputs.python_version }}-dependencies
+      # General note on this job: the main project uses poetry, but the project inside integration-tests/
+      # uses pdm. That's because integration-tests/ is a generated client-- the output from running the
+      # generator on a test API spec-- and the "make a pdm project" option was used in that process.
       - name: Install dependencies
         run: |
+          pip install poetry
           pip install pdm
           python -m venv .venv
-          pdm install
+          poetry install
       - name: Cache Generated Client Dependencies
         uses: actions/cache@v4
         with:
           path: integration-tests/.venv
-          key: ${{ runner.os }}-${{ steps.get_python_version.outputs.python_version }}-integration-dependencies-${{ hashFiles('**/pdm.lock') }}
+          key: ${{ runner.os }}-${{ steps.get_python_version.outputs.python_version }}-integration-dependencies-${{ hashFiles('**/poetry.lock') }}
           restore-keys: |
             ${{ runner.os }}-${{ steps.get_python_version.outputs.python_version }}-integration-dependencies
       - name: Set httpx version

.gitignore

@@ -36,4 +36,7 @@ htmlcov/
 # Generated end to end test data
 my-test-api-client/
 custom-e2e/
-3-1-features-client
+3-1-features-client
+localtest
+
+!tests/.env

CHANGELOG.md

@@ -13,6 +13,72 @@ Programmatic usage of this project (e.g., importing it as a Python module) and t
 
 The 0.x prefix used in versions for this project is to indicate that breaking changes are expected frequently (several times a year). Breaking changes will increment the minor number, all other changes will increment the patch number. You can track the progress toward 1.0 [here](https://github.com/openapi-generators/openapi-python-client/projects/2).
 
+## 0.23.0 (2024-12-24)
+
+### Breaking Changes
+
+#### Delete fewer files with `--overwrite`
+
+`--overwrite` will no longer delete the entire output directory before regenerating. Instead, it will only delete 
+specific, known directories within that directory. Right now, that is only the generated `models` and `api` directories.
+
+Other generated files, like `README.md`, will be overwritten. Extra files and directories outside of those listed above 
+will be left untouched, so you can any extra modules or files around while still updating `pyproject.toml` automatically.
+
+Closes #1105.
+
+### Features
+
+- Support httpx 0.28 (#1172)
+
+#### Add `generate_all_tags` config option
+
+You can now, optionally, generate **duplicate** endpoint functions/modules using _every_ tag for an endpoint,
+not just the first one, by setting `generate_all_tags: true` in your configuration file.
+
+### Fixes
+
+- Support Typer 0.14 and 0.15 (#1173)
+
+#### Fix minimum `attrs` version
+
+The minimum `attrs` dependency version was incorrectly set to 21.3.0. This has been corrected to 22.2.0, the minimum 
+supported version since `openapi-python-client` 0.19.1.
+
+Closes #1084, thanks @astralblue!
+
+#### Fix compatibility with Pydantic 2.10+
+
+##1176 by @Viicos
+
+Set `defer_build` to models that we know will fail to build, and call `model_rebuild`
+in the `__init__.py` file.
+
+## 0.22.0 (2024-11-23)
+
+### Breaking Changes
+
+#### Drop support for Python 3.8
+
+Python 3.8 is no longer supported. "New" 3.9 syntax, like generics on builtin collections, is used both in the generator 
+and the generated code.
+
+#### `type` is now a reserved field name
+
+Because `type` is used in type annotations now, it is no longer a valid field name. Fields which were previously named 
+`type` will be renamed to `type_`.
+
+### Features
+
+- Support Ruff 0.8 (#1169)
+
+## 0.21.7 (2024-10-28)
+
+### Fixes
+
+- allow required fields list to be specified as empty (#651) (#1149)
+- import cast for required const properties, since it's used in the template (#1153)
+
 ## 0.21.6 (2024-10-20)
 
 ### Features

CONTRIBUTING.md

@@ -1,84 +1,79 @@
-# Ways you can Contribute
+# Note: this is the fork of openapi-python-client maintained and used by Benchling.
 
-- Report bugs via [issues](https://github.com/openapi-generators/openapi-python-client/issues)
-- Request features via [discussions](https://github.com/openapi-generators/openapi-python-client/discussions)
-- Contribute code via [pull request](https://github.com/openapi-generators/openapi-python-client/pulls)
+If you want the official package, go to the upstream repository: https://github.com/openapi-generators/openapi-python-client
 
-## Reporting a bug
+For contribution guidelines (including contributing fixes from our fork to the upstream repo), see Benchling internal documentation.
 
-A bug is one of:
+This document mostly contains basic developer instructions.
 
-1. You get an exception when running the generator
-2. The generated code is invalid or incorrect
-3. An error message is unclear or incorrect
-4. Something which used to work no longer works, except:
-   1. Intentional breaking changes, which are documented in the [changelog](https://github.com/openapi-generators/openapi-python-client/blob/main/CHANGELOG.md)
-   2. Breaking changes to unstable features, like custom templates
+## Setting up environment
 
-If your issue does not fall under one of the above, it is not a bug; check out "[Requesting a feature](#requesting-a-feature).
+Create a virtualenv with the lowest compatible Python version (currently 3.9).
 
-### Report requirements
+To install dependencies:
 
-A bug report **must** have an OpenAPI document that can be used to replicate the bug. Reports without a valid document will be closed.
+```
+pip install poetry
+poetry install
+```
 
-## Requesting a feature
+## Running tests
 
-A feature is usually:
+See the [upstream repo]() for a full description of how the tests in this project are written.
 
-1. An improvement to the way the generated code works
-2. A feature of the generator itself which makes its use easier (e.g., a new config option)
-3. **Support for part of the OpenAPI spec**; this generator _does not yet_ support every OpenAPI feature, these missing features **are not bugs**.
+`poetry run task unit` runs only the basic unit tests.
 
-To request a feature:
+`poetry run task test` runs unit tests plus end-to-end tests.
 
-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:
-   1. Upvote it with the little arrow on the original post. This enables code contributors to prioritize the most-demanded features.
-   2. Optionally leave a comment describing why _you_ want the feature, if no existing thread already covers your use-case
-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".
+## Linting/type-checking
 
-## Contributing Code
+The project uses ruff. `poetry run task lint` and `poetry run task format` run `ruff check` and `ruff format`.
+
+`poetry run task mypy` runs `mypy` on only the package module (tests are excluded).
 
-### Setting up a Dev Environment
+`poetry run task check` runs all of those plus tests.
 
-1. Make sure you have [PDM](https://pdm-project.org) installed and up to date.
-2. Make sure you have a supported Python version (e.g. 3.8) installed.
-3. Use `pdm install` in the project directory to create a virtual environment with the relevant dependencies.
+## Contributing Code
+
+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.
 
 ### Writing tests
 
 All changes must be tested, I recommend writing the test first, then writing the code to make it pass. 100% code coverage is enforced in CI, a check will fail in GitHub if your code does not have 100% coverage. An HTML report will be added to the test artifacts in this case to help you locate missed lines.
 
 If you think that some of the added code is not testable (or testing it would add little value), mention that in your PR and we can discuss it.
 
-1. If you're adding support for a new OpenAPI feature or covering a new edge case, add an [end-to-end test](#end-to-end-tests)
-2. If you're modifying the way an existing feature works, make sure an existing test generates the _old_ code in `end_to_end_tests/golden-record`. You'll use this to check for the new code once your changes are complete.
-3. If you're improving an error or adding a new error, add a [unit test](#unit-tests)
+1. If you're adding support for a new OpenAPI feature or covering a new edge case, add [functional tests](#functional-tests), and optionally an [end-to-end snapshot test](#end-to-end-snapshot-tests).
+2. If you're modifying the way an existing feature works, make sure functional tests cover this case. Existing end-to-end snapshot tests might also be affected if you have changed what generated model/endpoint code looks like.
+3. If you're improving error handling or adding a new error, add [functional tests](#functional-tests).
+4. For tests of low-level pieces of code that are fairly self-contained, and not tightly coupled to other internal implementation details, you can use regular [unit tests](#unit-tests).
+
+#### End-to-end snapshot tests
 
-#### End-to-end tests
+This project aims to have all "happy paths" (types of code which _can_ be generated) covered by end-to-end tests. There are two types of these: snapshot tests, and functional tests.
 
-This project aims to have all "happy paths" (types of code which _can_ be generated) covered by end to end tests (snapshot tests). 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`.
+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.
 
-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_tets` directory:
+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`.
+
+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:
 
 1. `baseline_openapi_3.0.json` creates `golden-record` for testing OpenAPI 3.0 features
 2. `baseline_openapi_3.1.yaml` is checked against `golden-record` for testing OpenAPI 3.1 features (and ensuring consistency with 3.0)
 3. `test_custom_templates` are used with `baseline_openapi_3.0.json` to generate `custom-templates-golden-record` for testing custom templates
 4. `3.1_specific.openapi.yaml` is used to generate `test-3-1-golden-record` and test 3.1-specific features (things which do not have a 3.0 equivalent)
 
-#### Unit tests
-
-> **NOTE**: Several older-style unit tests using mocks exist in this project. These should be phased out rather than updated, as the tests are brittle and difficult to maintain. Only error cases should be tests with unit tests going forward.
+#### Functional tests
 
-In some cases, we need to test things which cannot be generated—like validating that errors are caught and handled correctly. These should be tested via unit tests in the `tests` directory, using the `pytest` framework.
+These are black-box tests that verify the runtime behavior of generated code, as well as the generator's validation behavior. They are also end-to-end tests, since they run the generator as a shell command.
 
-### Creating a Pull Request
+This can sometimes identify issues with error handling, validation logic, module imports, etc., that might be harder to diagnose via the snapshot tests, especially during development of a new feature. For instance, they can verify that JSON data is correctly decoded into model class attributes, or that the generator will emit an appropriate warning or error for an invalid spec.
 
-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).
+See [`end_to_end_tests/functional_tests`](./end_to_end_tests/functional_tests).
 
-### Wait for Review
+#### Unit tests
 
-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.
+These include:
 
-[Knope]: https://knope.tech
-[changesets]: https://knope.tech/reference/concepts/changeset/
-[Conventional Commits]: https://knope.tech/reference/concepts/conventional-commits/
+* 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.
+* 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.

README.md

@@ -1,9 +1,12 @@
-![Run Checks](https://github.com/openapi-generators/openapi-python-client/workflows/Run%20Checks/badge.svg)
-[![codecov](https://codecov.io/gh/openapi-generators/openapi-python-client/branch/main/graph/badge.svg)](https://codecov.io/gh/triaxtec/openapi-python-client)
 [![MIT license](https://img.shields.io/badge/License-MIT-blue.svg)](https://lbesson.mit-license.org/)
-[![Generic badge](https://img.shields.io/badge/type_checked-mypy-informational.svg)](https://mypy.readthedocs.io/en/stable/introduction.html)
-[![PyPI version shields.io](https://img.shields.io/pypi/v/openapi-python-client.svg)](https://pypi.python.org/pypi/openapi-python-client/)
-[![Downloads](https://static.pepy.tech/personalized-badge/openapi-python-client?period=total&units=international_system&left_color=blue&right_color=green&left_text=Downloads)](https://pepy.tech/project/openapi-python-client)
+
+# Note: this is the fork of openapi-python-client maintained and used by Benchling.
+
+If you want the official package, go to the upstream repository: https://github.com/openapi-generators/openapi-python-client
+
+The rest of this file is a copy of the upstream README, except for descriptions of extra options added in the Benchling fork. All other Benchling-specific notes are in our internal documentation.
+
+Benchling cannot provide any support for external use of this fork.
 
 # openapi-python-client
 
@@ -97,6 +100,16 @@ class_overrides:
 
 The easiest way to find what needs to be overridden is probably to generate your client and go look at everything in the `models` folder.
 
+### docstrings_on_attributes
+
+By default, when `openapi-python-client` generates a model class, it includes a list of attributes and their
+descriptions in the docstring for the class. If you set this option to `true`, then the attribute descriptions
+will be put in docstrings for the attributes themselves, and will not be in the class docstring.
+
+```yaml
+docstrings_on_attributes: true
+```
+
 ### literal_enums
 
 By default, `openapi-python-client` generates classes inheriting for `Enum` for enums. It can instead use `Literal` 
@@ -108,6 +121,16 @@ literal_enums: true
 
 This is especially useful if enum values, when transformed to their Python names, end up conflicting due to case sensitivity or special symbols.
 
+### generate_all_tags
+
+`openapi-python-client` generates module names within the `api` module based on the OpenAPI `tags` of each endpoint. 
+By default, only the _first_ tag is generated. If you want to generate **duplicate** endpoint functions using _every_ tag 
+listed, you can enable this option:
+
+```yaml
+generate_all_tags: true
+```
+
 ### project_name_override and package_name_override
 
 Used to change the name of generated client library project/package. If the project name is changed but an override for the package name