1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
|
%global _empty_manifest_terminate_build 0
Name: python-oapi
Version: 1.59.4
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.aliyun.com/pypi/web/packages/6b/de/a1b676c973cf5f085381d8b7e0c73473fa9679e8df69a04eb8477e382367/oapi-1.59.4.tar.gz
BuildArch: noarch
Requires: python3-pyyaml
Requires: python3-iso8601
Requires: python3-sob
Requires: python3-jsonpointer
Requires: python3-more-itertools
%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.4
%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
* Thu Jun 08 2023 Python_Bot <Python_Bot@openeuler.org> - 1.59.4-1
- Package Spec generated
|
