mergetbapi 1.3.7rc2__tar.gz → 1.3.9__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (24) hide show
  1. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/PKG-INFO +1 -1
  2. mergetbapi-1.3.9/mergetbapi/google/api/__init__.py +371 -0
  3. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/mergetbapi/grpc/gateway/protoc_gen_openapiv2/options/__init__.py +311 -216
  4. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/mergetbapi/portal/v1/__init__.py +56 -42
  5. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/mergetbapi/reconcile/__init__.py +53 -51
  6. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/mergetbapi/validator/__init__.py +20 -23
  7. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/mergetbapi/xir/__init__.py +6 -6
  8. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/mergetbapi.egg-info/PKG-INFO +1 -1
  9. mergetbapi-1.3.7rc2/mergetbapi/google/api/__init__.py +0 -255
  10. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/LICENSE.md +0 -0
  11. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/README.md +0 -0
  12. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/mergetbapi/__init__.py +0 -0
  13. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/mergetbapi/google/__init__.py +0 -0
  14. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/mergetbapi/grpc/__init__.py +0 -0
  15. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/mergetbapi/grpc/gateway/__init__.py +0 -0
  16. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/mergetbapi/grpc/gateway/protoc_gen_openapiv2/__init__.py +0 -0
  17. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/mergetbapi/portal/__init__.py +0 -0
  18. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/mergetbapi.egg-info/SOURCES.txt +0 -0
  19. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/mergetbapi.egg-info/dependency_links.txt +0 -0
  20. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/mergetbapi.egg-info/not-zip-safe +0 -0
  21. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/mergetbapi.egg-info/requires.txt +0 -0
  22. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/mergetbapi.egg-info/top_level.txt +0 -0
  23. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/setup.cfg +0 -0
  24. {mergetbapi-1.3.7rc2 → mergetbapi-1.3.9}/setup.py +0 -0
@@ -1,6 +1,6 @@
1
1
  Metadata-Version: 2.1
2
2
  Name: mergetbapi
3
- Version: 1.3.7rc2
3
+ Version: 1.3.9
4
4
  Summary: ('Client interface to the MergeTB API',)
5
5
  Home-page: https://gitlab.com/mergetb/api
6
6
  Author: Brian Kocoloski
@@ -0,0 +1,371 @@
1
+ # Generated by the protocol buffer compiler. DO NOT EDIT!
2
+ # sources: google/api/annotations.proto, google/api/field_behavior.proto, google/api/http.proto
3
+ # plugin: python-betterproto
4
+ # This file has been @generated
5
+
6
+ from dataclasses import dataclass
7
+ from typing import List
8
+
9
+ import betterproto
10
+
11
+
12
+ class FieldBehavior(betterproto.Enum):
13
+ """
14
+ An indicator of the behavior of a given field (for example, that a field
15
+ is required in requests, or given as output but ignored as input).
16
+ This **does not** change the behavior in protocol buffers itself; it only
17
+ denotes the behavior and may affect how API tooling handles the field.
18
+
19
+ Note: This enum **may** receive new values in the future.
20
+ """
21
+
22
+ UNSPECIFIED = 0
23
+ """Conventional default for enums. Do not use this."""
24
+
25
+ OPTIONAL = 1
26
+ """
27
+ Specifically denotes a field as optional.
28
+ While all fields in protocol buffers are optional, this may be specified
29
+ for emphasis if appropriate.
30
+ """
31
+
32
+ REQUIRED = 2
33
+ """
34
+ Denotes a field as required.
35
+ This indicates that the field **must** be provided as part of the request,
36
+ and failure to do so will cause an error (usually `INVALID_ARGUMENT`).
37
+ """
38
+
39
+ OUTPUT_ONLY = 3
40
+ """
41
+ Denotes a field as output only.
42
+ This indicates that the field is provided in responses, but including the
43
+ field in a request does nothing (the server *must* ignore it and
44
+ *must not* throw an error as a result of the field's presence).
45
+ """
46
+
47
+ INPUT_ONLY = 4
48
+ """
49
+ Denotes a field as input only.
50
+ This indicates that the field is provided in requests, and the
51
+ corresponding field is not included in output.
52
+ """
53
+
54
+ IMMUTABLE = 5
55
+ """
56
+ Denotes a field as immutable.
57
+ This indicates that the field may be set once in a request to create a
58
+ resource, but may not be changed thereafter.
59
+ """
60
+
61
+
62
+ @dataclass(eq=False, repr=False)
63
+ class Http(betterproto.Message):
64
+ """
65
+ Defines the HTTP configuration for an API service. It contains a list of
66
+ [HttpRule][google.api.HttpRule], each specifying the mapping of an RPC method
67
+ to one or more HTTP REST API methods.
68
+ """
69
+
70
+ rules: List["HttpRule"] = betterproto.message_field(1)
71
+ """
72
+ A list of HTTP configuration rules that apply to individual API methods.
73
+
74
+ **NOTE:** All service configuration rules follow "last one wins" order.
75
+ """
76
+
77
+ fully_decode_reserved_expansion: bool = betterproto.bool_field(2)
78
+ """
79
+ When set to true, URL path parmeters will be fully URI-decoded except in
80
+ cases of single segment matches in reserved expansion, where "%2F" will be
81
+ left encoded.
82
+
83
+ The default behavior is to not decode RFC 6570 reserved characters in multi
84
+ segment matches.
85
+ """
86
+
87
+
88
+ @dataclass(eq=False, repr=False)
89
+ class HttpRule(betterproto.Message):
90
+ """
91
+ `HttpRule` defines the mapping of an RPC method to one or more HTTP
92
+ REST API methods. The mapping specifies how different portions of the RPC
93
+ request message are mapped to URL path, URL query parameters, and
94
+ HTTP request body. The mapping is typically specified as an
95
+ `google.api.http` annotation on the RPC method,
96
+ see "google/api/annotations.proto" for details.
97
+
98
+ The mapping consists of a field specifying the path template and
99
+ method kind. The path template can refer to fields in the request
100
+ message, as in the example below which describes a REST GET
101
+ operation on a resource collection of messages:
102
+
103
+
104
+ service Messaging {
105
+ rpc GetMessage(GetMessageRequest) returns (Message) {
106
+ option (google.api.http).get = "/v1/messages/{message_id}/{sub.subfield}";
107
+ }
108
+ }
109
+ message GetMessageRequest {
110
+ message SubMessage {
111
+ string subfield = 1;
112
+ }
113
+ string message_id = 1; // mapped to the URL
114
+ SubMessage sub = 2; // `sub.subfield` is url-mapped
115
+ }
116
+ message Message {
117
+ string text = 1; // content of the resource
118
+ }
119
+
120
+ The same http annotation can alternatively be expressed inside the
121
+ `GRPC API Configuration` YAML file.
122
+
123
+ http:
124
+ rules:
125
+ - selector: <proto_package_name>.Messaging.GetMessage
126
+ get: /v1/messages/{message_id}/{sub.subfield}
127
+
128
+ This definition enables an automatic, bidrectional mapping of HTTP
129
+ JSON to RPC. Example:
130
+
131
+ HTTP | RPC
132
+ -----|-----
133
+ `GET /v1/messages/123456/foo` | `GetMessage(message_id: "123456" sub: SubMessage(subfield: "foo"))`
134
+
135
+ In general, not only fields but also field paths can be referenced
136
+ from a path pattern. Fields mapped to the path pattern cannot be
137
+ repeated and must have a primitive (non-message) type.
138
+
139
+ Any fields in the request message which are not bound by the path
140
+ pattern automatically become (optional) HTTP query
141
+ parameters. Assume the following definition of the request message:
142
+
143
+
144
+ service Messaging {
145
+ rpc GetMessage(GetMessageRequest) returns (Message) {
146
+ option (google.api.http).get = "/v1/messages/{message_id}";
147
+ }
148
+ }
149
+ message GetMessageRequest {
150
+ message SubMessage {
151
+ string subfield = 1;
152
+ }
153
+ string message_id = 1; // mapped to the URL
154
+ int64 revision = 2; // becomes a parameter
155
+ SubMessage sub = 3; // `sub.subfield` becomes a parameter
156
+ }
157
+
158
+
159
+ This enables a HTTP JSON to RPC mapping as below:
160
+
161
+ HTTP | RPC
162
+ -----|-----
163
+ `GET /v1/messages/123456?revision=2&sub.subfield=foo` | `GetMessage(message_id: "123456" revision: 2 sub: SubMessage(subfield: "foo"))`
164
+
165
+ Note that fields which are mapped to HTTP parameters must have a
166
+ primitive type or a repeated primitive type. Message types are not
167
+ allowed. In the case of a repeated type, the parameter can be
168
+ repeated in the URL, as in `...?param=A&param=B`.
169
+
170
+ For HTTP method kinds which allow a request body, the `body` field
171
+ specifies the mapping. Consider a REST update method on the
172
+ message resource collection:
173
+
174
+
175
+ service Messaging {
176
+ rpc UpdateMessage(UpdateMessageRequest) returns (Message) {
177
+ option (google.api.http) = {
178
+ put: "/v1/messages/{message_id}"
179
+ body: "message"
180
+ };
181
+ }
182
+ }
183
+ message UpdateMessageRequest {
184
+ string message_id = 1; // mapped to the URL
185
+ Message message = 2; // mapped to the body
186
+ }
187
+
188
+
189
+ The following HTTP JSON to RPC mapping is enabled, where the
190
+ representation of the JSON in the request body is determined by
191
+ protos JSON encoding:
192
+
193
+ HTTP | RPC
194
+ -----|-----
195
+ `PUT /v1/messages/123456 { "text": "Hi!" }` | `UpdateMessage(message_id: "123456" message { text: "Hi!" })`
196
+
197
+ The special name `*` can be used in the body mapping to define that
198
+ every field not bound by the path template should be mapped to the
199
+ request body. This enables the following alternative definition of
200
+ the update method:
201
+
202
+ service Messaging {
203
+ rpc UpdateMessage(Message) returns (Message) {
204
+ option (google.api.http) = {
205
+ put: "/v1/messages/{message_id}"
206
+ body: "*"
207
+ };
208
+ }
209
+ }
210
+ message Message {
211
+ string message_id = 1;
212
+ string text = 2;
213
+ }
214
+
215
+
216
+ The following HTTP JSON to RPC mapping is enabled:
217
+
218
+ HTTP | RPC
219
+ -----|-----
220
+ `PUT /v1/messages/123456 { "text": "Hi!" }` | `UpdateMessage(message_id: "123456" text: "Hi!")`
221
+
222
+ Note that when using `*` in the body mapping, it is not possible to
223
+ have HTTP parameters, as all fields not bound by the path end in
224
+ the body. This makes this option more rarely used in practice of
225
+ defining REST APIs. The common usage of `*` is in custom methods
226
+ which don't use the URL at all for transferring data.
227
+
228
+ It is possible to define multiple HTTP methods for one RPC by using
229
+ the `additional_bindings` option. Example:
230
+
231
+ service Messaging {
232
+ rpc GetMessage(GetMessageRequest) returns (Message) {
233
+ option (google.api.http) = {
234
+ get: "/v1/messages/{message_id}"
235
+ additional_bindings {
236
+ get: "/v1/users/{user_id}/messages/{message_id}"
237
+ }
238
+ };
239
+ }
240
+ }
241
+ message GetMessageRequest {
242
+ string message_id = 1;
243
+ string user_id = 2;
244
+ }
245
+
246
+
247
+ This enables the following two alternative HTTP JSON to RPC
248
+ mappings:
249
+
250
+ HTTP | RPC
251
+ -----|-----
252
+ `GET /v1/messages/123456` | `GetMessage(message_id: "123456")`
253
+ `GET /v1/users/me/messages/123456` | `GetMessage(user_id: "me" message_id: "123456")`
254
+
255
+ # Rules for HTTP mapping
256
+
257
+ The rules for mapping HTTP path, query parameters, and body fields
258
+ to the request message are as follows:
259
+
260
+ 1. The `body` field specifies either `*` or a field path, or is
261
+ omitted. If omitted, it indicates there is no HTTP request body.
262
+ 2. Leaf fields (recursive expansion of nested messages in the
263
+ request) can be classified into three types:
264
+ (a) Matched in the URL template.
265
+ (b) Covered by body (if body is `*`, everything except (a) fields;
266
+ else everything under the body field)
267
+ (c) All other fields.
268
+ 3. URL query parameters found in the HTTP request are mapped to (c) fields.
269
+ 4. Any body sent with an HTTP request can contain only (b) fields.
270
+
271
+ The syntax of the path template is as follows:
272
+
273
+ Template = "/" Segments [ Verb ] ;
274
+ Segments = Segment { "/" Segment } ;
275
+ Segment = "*" | "**" | LITERAL | Variable ;
276
+ Variable = "{" FieldPath [ "=" Segments ] "}" ;
277
+ FieldPath = IDENT { "." IDENT } ;
278
+ Verb = ":" LITERAL ;
279
+
280
+ The syntax `*` matches a single path segment. The syntax `**` matches zero
281
+ or more path segments, which must be the last part of the path except the
282
+ `Verb`. The syntax `LITERAL` matches literal text in the path.
283
+
284
+ The syntax `Variable` matches part of the URL path as specified by its
285
+ template. A variable template must not contain other variables. If a variable
286
+ matches a single path segment, its template may be omitted, e.g. `{var}`
287
+ is equivalent to `{var=*}`.
288
+
289
+ If a variable contains exactly one path segment, such as `"{var}"` or
290
+ `"{var=*}"`, when such a variable is expanded into a URL path, all characters
291
+ except `[-_.~0-9a-zA-Z]` are percent-encoded. Such variables show up in the
292
+ Discovery Document as `{var}`.
293
+
294
+ If a variable contains one or more path segments, such as `"{var=foo/*}"`
295
+ or `"{var=**}"`, when such a variable is expanded into a URL path, all
296
+ characters except `[-_.~/0-9a-zA-Z]` are percent-encoded. Such variables
297
+ show up in the Discovery Document as `{+var}`.
298
+
299
+ NOTE: While the single segment variable matches the semantics of
300
+ [RFC 6570](https://tools.ietf.org/html/rfc6570) Section 3.2.2
301
+ Simple String Expansion, the multi segment variable **does not** match
302
+ RFC 6570 Reserved Expansion. The reason is that the Reserved Expansion
303
+ does not expand special characters like `?` and `#`, which would lead
304
+ to invalid URLs.
305
+
306
+ NOTE: the field paths in variables and in the `body` must not refer to
307
+ repeated fields or map fields.
308
+ """
309
+
310
+ selector: str = betterproto.string_field(1)
311
+ """
312
+ Selects methods to which this rule applies.
313
+
314
+ Refer to [selector][google.api.DocumentationRule.selector] for syntax details.
315
+ """
316
+
317
+ get: str = betterproto.string_field(2, group="pattern")
318
+ """Used for listing and getting information about resources."""
319
+
320
+ put: str = betterproto.string_field(3, group="pattern")
321
+ """Used for updating a resource."""
322
+
323
+ post: str = betterproto.string_field(4, group="pattern")
324
+ """Used for creating a resource."""
325
+
326
+ delete: str = betterproto.string_field(5, group="pattern")
327
+ """Used for deleting a resource."""
328
+
329
+ patch: str = betterproto.string_field(6, group="pattern")
330
+ """Used for updating a resource."""
331
+
332
+ custom: "CustomHttpPattern" = betterproto.message_field(8, group="pattern")
333
+ """
334
+ The custom pattern is used for specifying an HTTP method that is not
335
+ included in the `pattern` field, such as HEAD, or "*" to leave the
336
+ HTTP method unspecified for this rule. The wild-card rule is useful
337
+ for services that provide content to Web (HTML) clients.
338
+ """
339
+
340
+ body: str = betterproto.string_field(7)
341
+ """
342
+ The name of the request field whose value is mapped to the HTTP body, or
343
+ `*` for mapping all fields not captured by the path pattern to the HTTP
344
+ body. NOTE: the referred field must not be a repeated field and must be
345
+ present at the top-level of request message type.
346
+ """
347
+
348
+ response_body: str = betterproto.string_field(12)
349
+ """
350
+ Optional. The name of the response field whose value is mapped to the HTTP
351
+ body of response. Other response fields are ignored. When
352
+ not set, the response message will be used as HTTP body of response.
353
+ """
354
+
355
+ additional_bindings: List["HttpRule"] = betterproto.message_field(11)
356
+ """
357
+ Additional HTTP bindings for the selector. Nested bindings must
358
+ not contain an `additional_bindings` field themselves (that is,
359
+ the nesting may only be one level deep).
360
+ """
361
+
362
+
363
+ @dataclass(eq=False, repr=False)
364
+ class CustomHttpPattern(betterproto.Message):
365
+ """A custom pattern is used for defining custom HTTP verb."""
366
+
367
+ kind: str = betterproto.string_field(1)
368
+ """The name of this custom HTTP verb."""
369
+
370
+ path: str = betterproto.string_field(2)
371
+ """The path matched by this custom verb."""