automatic import of python-oapi

3 files changed, 257 insertions, 0 deletions

diff --git a/.gitignore b/.gitignore
index e69de29..4f64298 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/oapi-1.59.0.tar.gz
diff --git a/python-oapi.spec b/python-oapi.spec
new file mode 100644
index 0000000..e553eec
--- /dev/null
+++ b/python-oapi.spec
@@ -0,0 +1,255 @@
+%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 <Python_Bot@openeuler.org> - 1.59.0-1
+- Package Spec generated
diff --git a/sources b/sources
new file mode 100644
index 0000000..bb3904e
--- /dev/null
+++ b/sources
@@ -0,0 +1 @@
+e89e9c084d11469d2a54799963491106  oapi-1.59.0.tar.gz