%global _empty_manifest_terminate_build 0 Name: python-oapi Version: 1.59.0 Release: 1 Summary: An SDK for parsing OpenAPI (Swagger) 2.0 - 3.0 specifications License: MIT URL: https://github.com/enorganic/oapi Source0: https://mirrors.nju.edu.cn/pypi/web/packages/28/34/dd5e1dd22c66b04995851e504197c2f2923288733eb92c13191f4b063839/oapi-1.59.0.tar.gz BuildArch: noarch Requires: python3-pyyaml Requires: python3-iso8601 Requires: python3-sob Requires: python3-jsonpointer Requires: python3-more-itertools Requires: python3-dataclasses %description # oapi `oapi` is a library and CLI for authoring python data models (for clients *or* servers), and/or client libraries, for web APIs, based on an OpenAPI specification (both OpenAPI/Swagger [version 2](https://bit.ly/36VneDU) and [version 3](https://bit.ly/3OHGRQV) are supported). `oapi`-generated packages/modules differ from those generated by other tools (including but not limited to [swagger-codegen](https://github.com/swagger-api/swagger-codegen)) in that `oapi` generates a data model which enforces the schemas defined in the OpenAPI specification. This means that request and response objects cannot comprise data types which differ from those specified in the spec, and objects cannot have properties which are not defined. If an API will add properties to an object which are not explicitly defined in the schema properties, that object should have an ["additionalProperties"](https://bit.ly/3LuUlxm) attribute, in which case `oapi` will treat these objects as dictionaries/mappings. `oapi` also fully supports polymorphism when a schema has an "anyOf", "allOf", or "oneOf" attribute (although `oapi` does not *require* a [discriminator](https://bit.ly/3vPvMEW) to be defined). This design decision could prove to be an annoyance to lazy developers of client applications, since inaccurate OpenAPI schemas are endemic to many organizations. The author of this library, however, asserts that end-to-end data validation is absolutely essential for applications which are part of a critical data pipeline. The author of this library is also of the opinion that when encountering inaccurate OpenAPI specifications, you should fix the spec, and if you are not the owner of the spec (and can't convince the owner to fix it), you should script your fix in order to apply that same fix to future versions of the specification. Notable features of an `oapi` generated client/model library include: - `oapi` generated data models and clients are fully type-hinted (they will pass inspection by `mypy`). - `oapi` generated data models and clients adhere to PEP-8 formatting standards, and will pass inspection by `flake8` (with the default options). - `oapi` generated data models and clients include docstrings for all models, model properties, client methods, and client method parameters, inferred from "description" and "summary" attributes of elements within the specification. - `oapi` generated clients will handle the most common server-to-server authentication methods out-of-box, including the OAuth2 authorization code flow (client_id/client_secret), API keys, bearer tokens, HTTP basic auth, and most cookie-based authentication patterns. Custom authentication methods are also easily accomplished by specifying custom base classes and/or passing initialization decorators to the `oapi client` shell command or to the `oapi.client.create()` function. - `oapi` generated clients and models are easily updated. For instance: `oapi` generated data model classes can be renamed using your favorite IDE's refactoring tools, and subsequent updates to that data model (such as to reflect minor-version updates to the spec which add endpoints, schemas, parameters, etc.) will retain your new class names, so long as the schema from which the class was generated remains in the same location within the spec. Class naming can also be customized by passing a custom hook to the *get_class_name_from_pointer* parameter for `oapi.model.Module` or `oapi.model.create`. TODO: Finish README.md %package -n python3-oapi Summary: An SDK for parsing OpenAPI (Swagger) 2.0 - 3.0 specifications Provides: python-oapi BuildRequires: python3-devel BuildRequires: python3-setuptools BuildRequires: python3-pip %description -n python3-oapi # oapi `oapi` is a library and CLI for authoring python data models (for clients *or* servers), and/or client libraries, for web APIs, based on an OpenAPI specification (both OpenAPI/Swagger [version 2](https://bit.ly/36VneDU) and [version 3](https://bit.ly/3OHGRQV) are supported). `oapi`-generated packages/modules differ from those generated by other tools (including but not limited to [swagger-codegen](https://github.com/swagger-api/swagger-codegen)) in that `oapi` generates a data model which enforces the schemas defined in the OpenAPI specification. This means that request and response objects cannot comprise data types which differ from those specified in the spec, and objects cannot have properties which are not defined. If an API will add properties to an object which are not explicitly defined in the schema properties, that object should have an ["additionalProperties"](https://bit.ly/3LuUlxm) attribute, in which case `oapi` will treat these objects as dictionaries/mappings. `oapi` also fully supports polymorphism when a schema has an "anyOf", "allOf", or "oneOf" attribute (although `oapi` does not *require* a [discriminator](https://bit.ly/3vPvMEW) to be defined). This design decision could prove to be an annoyance to lazy developers of client applications, since inaccurate OpenAPI schemas are endemic to many organizations. The author of this library, however, asserts that end-to-end data validation is absolutely essential for applications which are part of a critical data pipeline. The author of this library is also of the opinion that when encountering inaccurate OpenAPI specifications, you should fix the spec, and if you are not the owner of the spec (and can't convince the owner to fix it), you should script your fix in order to apply that same fix to future versions of the specification. Notable features of an `oapi` generated client/model library include: - `oapi` generated data models and clients are fully type-hinted (they will pass inspection by `mypy`). - `oapi` generated data models and clients adhere to PEP-8 formatting standards, and will pass inspection by `flake8` (with the default options). - `oapi` generated data models and clients include docstrings for all models, model properties, client methods, and client method parameters, inferred from "description" and "summary" attributes of elements within the specification. - `oapi` generated clients will handle the most common server-to-server authentication methods out-of-box, including the OAuth2 authorization code flow (client_id/client_secret), API keys, bearer tokens, HTTP basic auth, and most cookie-based authentication patterns. Custom authentication methods are also easily accomplished by specifying custom base classes and/or passing initialization decorators to the `oapi client` shell command or to the `oapi.client.create()` function. - `oapi` generated clients and models are easily updated. For instance: `oapi` generated data model classes can be renamed using your favorite IDE's refactoring tools, and subsequent updates to that data model (such as to reflect minor-version updates to the spec which add endpoints, schemas, parameters, etc.) will retain your new class names, so long as the schema from which the class was generated remains in the same location within the spec. Class naming can also be customized by passing a custom hook to the *get_class_name_from_pointer* parameter for `oapi.model.Module` or `oapi.model.create`. TODO: Finish README.md %package help Summary: Development documents and examples for oapi Provides: python3-oapi-doc %description help # oapi `oapi` is a library and CLI for authoring python data models (for clients *or* servers), and/or client libraries, for web APIs, based on an OpenAPI specification (both OpenAPI/Swagger [version 2](https://bit.ly/36VneDU) and [version 3](https://bit.ly/3OHGRQV) are supported). `oapi`-generated packages/modules differ from those generated by other tools (including but not limited to [swagger-codegen](https://github.com/swagger-api/swagger-codegen)) in that `oapi` generates a data model which enforces the schemas defined in the OpenAPI specification. This means that request and response objects cannot comprise data types which differ from those specified in the spec, and objects cannot have properties which are not defined. If an API will add properties to an object which are not explicitly defined in the schema properties, that object should have an ["additionalProperties"](https://bit.ly/3LuUlxm) attribute, in which case `oapi` will treat these objects as dictionaries/mappings. `oapi` also fully supports polymorphism when a schema has an "anyOf", "allOf", or "oneOf" attribute (although `oapi` does not *require* a [discriminator](https://bit.ly/3vPvMEW) to be defined). This design decision could prove to be an annoyance to lazy developers of client applications, since inaccurate OpenAPI schemas are endemic to many organizations. The author of this library, however, asserts that end-to-end data validation is absolutely essential for applications which are part of a critical data pipeline. The author of this library is also of the opinion that when encountering inaccurate OpenAPI specifications, you should fix the spec, and if you are not the owner of the spec (and can't convince the owner to fix it), you should script your fix in order to apply that same fix to future versions of the specification. Notable features of an `oapi` generated client/model library include: - `oapi` generated data models and clients are fully type-hinted (they will pass inspection by `mypy`). - `oapi` generated data models and clients adhere to PEP-8 formatting standards, and will pass inspection by `flake8` (with the default options). - `oapi` generated data models and clients include docstrings for all models, model properties, client methods, and client method parameters, inferred from "description" and "summary" attributes of elements within the specification. - `oapi` generated clients will handle the most common server-to-server authentication methods out-of-box, including the OAuth2 authorization code flow (client_id/client_secret), API keys, bearer tokens, HTTP basic auth, and most cookie-based authentication patterns. Custom authentication methods are also easily accomplished by specifying custom base classes and/or passing initialization decorators to the `oapi client` shell command or to the `oapi.client.create()` function. - `oapi` generated clients and models are easily updated. For instance: `oapi` generated data model classes can be renamed using your favorite IDE's refactoring tools, and subsequent updates to that data model (such as to reflect minor-version updates to the spec which add endpoints, schemas, parameters, etc.) will retain your new class names, so long as the schema from which the class was generated remains in the same location within the spec. Class naming can also be customized by passing a custom hook to the *get_class_name_from_pointer* parameter for `oapi.model.Module` or `oapi.model.create`. TODO: Finish README.md %prep %autosetup -n oapi-1.59.0 %build %py3_build %install %py3_install install -d -m755 %{buildroot}/%{_pkgdocdir} if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi pushd %{buildroot} if [ -d usr/lib ]; then find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/lib64 ]; then find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/bin ]; then find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/sbin ]; then find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst fi touch doclist.lst if [ -d usr/share/man ]; then find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst fi popd mv %{buildroot}/filelist.lst . mv %{buildroot}/doclist.lst . %files -n python3-oapi -f filelist.lst %dir %{python3_sitelib}/* %files help -f doclist.lst %{_docdir}/* %changelog * Mon May 15 2023 Python_Bot - 1.59.0-1 - Package Spec generated