Swagger-to
==========
.. image:: https://github.com/Parquery/swagger-to/workflows/Check-push/badge.svg
:target: https://github.com/Parquery/swagger-to/actions?query=workflow%3ACheck-push
:alt: Check status
.. image:: https://badge.fury.io/py/swagger-to.svg
:target: https://pypi.org/project/swagger-to/
:alt: PyPI - version
.. image:: https://img.shields.io/pypi/pyversions/swagger-to.svg
:target: https://pypi.org/project/swagger-to/
:alt: PyPI - Python Version
Swagger-to generates server and client code from Swagger (OpenAPI 2.0) specification; written in Python 3.
We wanted a code generator that is 1) easy to write, maintain and extend and that 2) produces readable code.
To achieve this, we wrote the tool in Python which we found to be far superior for code generation compared with other
languages such as Go and Java. Since the original Swagger specification can become quite complex, we introduce an
intermediate representation layer after parsing the specification and before generating the code. This layer allowed us
to substantially simplify the generation code since it reduced the impedance mismatch by operating on abstract
constructs (such as Maps) instead of directly referring to "raw" Swagger constructs (such as additional properties of
an object).
The underlying language (Python), readable generated code and the intermediate representation layer are the three main
differentiators to other similar code generation projects.
Supported languages:
==================== ====== ======
Language Client Server
==================== ====== ======
Elm x
Go x
Python x
Typescript + Angular x
==================== ====== ======
Missing Features
----------------
Due to the lack of time, we can not cover all of the Swagger specification. The current generators work well for all of
our simple and not-so-simple use cases. We believe they can also cover most of the other people's needs as well.
Here is a non-comprehensive list:
* **anonymous objects**. We do not support anonymous objects in the definitions. Please define all objects as top level
definitions.
* **parameters**. Go server and Python client support query, body, path and header parameters.
Elm and Typescript + Angular clients support only query, body and path parameters.
Cookie parameters are not supported.
* **default values**. We do not support default values due to the impedance mismatch between JSON and the target languages.
* **validation of responses**. Responses from the server are not validated due to the complexity and the run-time overhead.
* **type hierarchy**. We simply stack all the properties from ``allOf`` together without introducing any type hierarchy.
First, this is due to Go and Elm which do not embrace type hierarchies. For example, you could use structural typing
in Go, but then every piece of data would have to be a pointer with an interface which is clumsy.
Second, it is due to expediency, since stacking properties in the intermediate representation layer means we do not have
to care about them in upper, language-specific layers.
Related Projects
================
We list here some of the related projects and comment why they did not satisfy our requirements.
* https://github.com/go-swagger/go-swagger produces code which looked a bit too clumsy for us.
* https://github.com/swagger-api/swagger-codegen written in Java and hence hard for us to extend and customize.
* https://grpc.io/ gRPC is great when remote procedure calls are all you need. However, it requires you to use HTTP 2,
and we found it hard to integrate with widely-used browsers as clients.
Additionally, streaming files was not directly supported (see https://github.com/grpc/grpc-go/issues/414).
* https://github.com/grpc-ecosystem/grpc-gateway provides a JSON gateway to gRPC. We found that it added an additional
layer of complexity (especially when the number of client/server pairs grow), and preferred to have a simple solution
with a single code generation tool.
* https://github.com/twitchtv/twirp a (better?) alternative if you only want to generate remote procedure calls based on
JSON using protocol buffers to specify the API. It forces you to stick to its representation, though, and does not
allow you to use an arbitrary Swagger specification. This is problematic when the interface is imposed on you from
outside (*e.g.*, by customers).
Installation
============
* Create a virtual environment:
.. code-block:: bash
python3 -m venv venv3
* Activate it:
.. code-block:: bash
source venv3/bin/activate
* Install swagger_to with pip:
.. code-block:: bash
pip3 install swagger_to
Usage
=====
To generate code, you need to invoke one of the ``swagger_to_*.py`` scripts. If the generated code exists, you need to
specify ``--force`` command-line argument in order to overwrite the existing files.
We use the tag `name` to designate the generate code (*e.g.*, package name in the Go server or service name in the
Python client code). See `this example <tests/cases/py_client/general/swagger.yaml#L10>`_ from the test cases.
Elm Client
----------
To generate an Elm client from a Swagger specification at ``/some/path/swagger.yaml``, invoke:
.. code-block:: bash
swagger_to_elm_client.py \
--swagger_path /some/path/swagger.yaml \
--outdir /some/elm/path/src/your-client-directory
The generated code will have the following structure in ``/some/elm/path/src/your-client-directory``:
=========================== ========================================================================================
File Description
=========================== ========================================================================================
``Client.elm`` Elm Client, containing Models, Encoders, Decoders and Http Requests.
``elm-package.sample.json`` The Elm JSON Package containing the libraries used in Client.elm.
=========================== ========================================================================================
Two non-standard libraries are used in the Client:
* "NoRedInk/elm-decode-pipeline" is used to decode JSON objects in a more scalable way than the one supported by the
elm-lang libraries; and
* "elm-community/json-extra" is needed to encode Dict variables.
We use Elm's built-in Int type to represent both 32 and 64-bit integers. Please be careful: Elm depends on JavaScript
which uses solely double-precision floats both for integers and for floating-point numbers, which can lead to
unexpected truncation.
Go Server
---------
To generate a Go server from a Swagger specification at ``/some/path/swagger.yaml``, invoke:
.. code-block:: bash
swagger_to_go_server.py \
--swagger_path /some/path/swagger.yaml \
--outdir /some/go/path/src/your-server-package
The generated code will have the following structure in ``/some/go/path/src/your-server-package``:
========================== ========================================================================================
File Description
========================== ========================================================================================
``types.go`` Go type definitions
``jsonschemas.go`` JSON schemas used to validate the input (using https://github.com/xeipuuv/gojsonschema)
``routes.go`` Router specification
``handler.go`` Handler interface
``handler_impl.sample.go`` Empty implementation of the handler
========================== ========================================================================================
All the types defined in the Swagger are translated to ``types.go``. The routing and validation code around
the endpoints is generated in ``jsonschemas.go`` and ``routes.go``.
The handler interface is given in ``handler.go``. You need to implement the handler logic yourself. You can use
``handler_impl.sample.go`` as a starting point. We usually just copy/paste it to ``handler_impl.go`` and ignore
``handler_impl.sample.go`` in our repositories (*e.g.*, by adding it to ``.gitignore``).
In face of Swagger (*i.e.* API) changes, our workflow includes regenerating the code and using a diff tool
like ``meld`` to sync the "old" ``handler_impl.go`` with the new ``handler_impl.sample.go``.
Pecularities
~~~~~~~~~~~~
* **parameters**. We decided to generate the code to extract the parameters only from queries, bodies and paths.
It seemed difficult to automatically generate the code to extract form data arguments which would cover all the edge
cases (such as files and duplicate entries). We still generate the handler function, but leave it to the programmer
to extract these arguments manually from the request.
Due to lack of time, we did not implement header and cookie parameters. Contributions for these features are highly
welcome!
* **response**. The auto-generated code does not check that the response conforms to the specification. We found such
checks to be unnecessarily constraining and almost impossible to implement for all the use cases.
Python Client
-------------
To generate a Python 3 client from a Swagger specification at ``/some/path/swagger.yaml``, invoke:
.. code-block:: bash
swagger_to_py_client.py \
--swagger_path /some/path/swagger.yaml \
--outpath /some/py/path/your_client_module.py
The generated client uses ``requests`` library.
Since input checks need to be performed by the server anyhow, we decided not to keep the code generator simple and
more maintainable by including only the rudimentary type checks on the inputs. Hence all the sophisticated checks
such as string patterns or casting of a Python integer to int32 are deliberately excluded. Analogously, we also
do not validate the output coming from the server.
If time ever permits, we would like to include both more fine-grained input and output validation. At the moment,
we did not confront any problems in the development process.
Typescript+Angular Client
-------------------------
To generate a Python client from a Swagger specification at ``/some/path/swagger.yaml``, invoke:
.. code-block:: bash
swagger_to_ts_angular5_client.py \
--swagger_path /some/path/swagger.yaml \
--outpath /some/typescript/path/your_client.ts
The generated client uses Angular ``http`` library. For the same reasons as for Python client, no checks are performed
neither on the input nor on the output.
We use Typescript's built-in number type to represent both 32 and 64-bit integers. Please be careful: Typescript
depends on JavaScript which uses solely double-precision floats both for integers and for floating-point numbers,
which can lead to unexpected truncation.
Style Check
-----------
We found it important to have a uniform documentation style across all the Swagger specifications in an organization.
To that end, swagger_to includes an utility to automatically check the style such as casing of the definition names,
property names, descriptions and verb moods (present tense instead of imperative).To check the compliance of a Swagger
specification at ``/some/path/swagger.yaml`` to the Swagger style guides, invoke:
.. code-block:: bash
swagger_style.py \
--swagger_path /some/path/swagger.yaml
The following checks are performed:
* The Swagger name is in camel case, its description capitalized, and the base path starts with a slash.
* Top level type definitions are in capitalized camel case, and properties are in snake case.
* Endpoint paths, operation_id and parameter names are in camel case.
* All descriptions:
* start with a present tense verb, whose first letter is lower case;
* have no leading or trailing whitespaces, tabs or new lines;
* contain either one line, or three or more, in which case the second is empty;
* end with a period.
* Endpoint paths start with a slash, and the responses contain "200" and "default".
The script call returns 0 in case of no violations found, 1 in case of failed checks or 2 in case of illegal usage.
Examples
========
You can find the following examples useful for development:
* Swagger API: https://github.com/Parquery/swagger-to/blob/master/tests/cases/go_server/general/swagger.yaml
* Go Server generated code: https://github.com/Parquery/swagger-to/tree/master/tests/cases/go_server/general
* Py Client generated code: https://github.com/Parquery/swagger-to/blob/master/tests/cases/py_client/general/client.py
* Elm client generated code: https://github.com/Parquery/swagger-to/blob/master/tests/cases/elm_client/general/Client.elm
Development
===========
* Check out the repository.
* In the repository root, create the virtual environment:
.. code-block:: bash
python3 -m venv venv3
* Activate the virtual environment:
.. code-block:: bash
source venv3/bin/activate
* Install the development dependencies:
.. code-block:: bash
pip3 install -e .[dev]
* Run `precommit.py` to execute pre-commit checks locally.
Versioning
==========
We follow `Semantic Versioning <http://semver.org/spec/v1.0.0.html>`_. The version X.Y.Z indicates:
* X is the major version (backward-incompatible),
* Y is the minor version (backward-compatible), and
* Z is the patch version (backward-compatible bug fix).
Raw data
{
"_id": null,
"home_page": "https://github.com/Parquery/swagger-to",
"name": "swagger-to",
"maintainer": "",
"docs_url": null,
"requires_python": "",
"maintainer_email": "",
"keywords": "swagger code generation python elm go typescript server client angular",
"author": "Marko Ristin",
"author_email": "marko@parquery.com",
"download_url": "https://files.pythonhosted.org/packages/3e/e0/0bc07fa90a5d64c5cfd88845a313d9729af86c1c3d0e772bc8e3942e22ab/swagger_to-5.0.1.tar.gz",
"platform": null,
"description": "Swagger-to\r\n==========\r\n\r\n.. image:: https://github.com/Parquery/swagger-to/workflows/Check-push/badge.svg\r\n :target: https://github.com/Parquery/swagger-to/actions?query=workflow%3ACheck-push\r\n :alt: Check status\r\n\r\n.. image:: https://badge.fury.io/py/swagger-to.svg\r\n :target: https://pypi.org/project/swagger-to/\r\n :alt: PyPI - version\r\n\r\n.. image:: https://img.shields.io/pypi/pyversions/swagger-to.svg\r\n :target: https://pypi.org/project/swagger-to/\r\n :alt: PyPI - Python Version\r\n\r\nSwagger-to generates server and client code from Swagger (OpenAPI 2.0) specification; written in Python 3.\r\n\r\nWe wanted a code generator that is 1) easy to write, maintain and extend and that 2) produces readable code.\r\n\r\nTo achieve this, we wrote the tool in Python which we found to be far superior for code generation compared with other\r\nlanguages such as Go and Java. Since the original Swagger specification can become quite complex, we introduce an\r\nintermediate representation layer after parsing the specification and before generating the code. This layer allowed us\r\nto substantially simplify the generation code since it reduced the impedance mismatch by operating on abstract\r\nconstructs (such as Maps) instead of directly referring to \"raw\" Swagger constructs (such as additional properties of\r\nan object).\r\n\r\nThe underlying language (Python), readable generated code and the intermediate representation layer are the three main\r\ndifferentiators to other similar code generation projects.\r\n\r\nSupported languages:\r\n\r\n==================== ====== ======\r\nLanguage Client Server\r\n==================== ====== ======\r\nElm x\r\nGo x\r\nPython x\r\nTypescript + Angular x\r\n==================== ====== ======\r\n\r\nMissing Features\r\n----------------\r\nDue to the lack of time, we can not cover all of the Swagger specification. The current generators work well for all of\r\nour simple and not-so-simple use cases. We believe they can also cover most of the other people's needs as well.\r\n\r\nHere is a non-comprehensive list:\r\n\r\n* **anonymous objects**. We do not support anonymous objects in the definitions. Please define all objects as top level\r\n definitions.\r\n\r\n* **parameters**. Go server and Python client support query, body, path and header parameters.\r\n Elm and Typescript + Angular clients support only query, body and path parameters.\r\n Cookie parameters are not supported.\r\n\r\n* **default values**. We do not support default values due to the impedance mismatch between JSON and the target languages.\r\n\r\n* **validation of responses**. Responses from the server are not validated due to the complexity and the run-time overhead.\r\n\r\n* **type hierarchy**. We simply stack all the properties from ``allOf`` together without introducing any type hierarchy.\r\n First, this is due to Go and Elm which do not embrace type hierarchies. For example, you could use structural typing\r\n in Go, but then every piece of data would have to be a pointer with an interface which is clumsy.\r\n Second, it is due to expediency, since stacking properties in the intermediate representation layer means we do not have\r\n to care about them in upper, language-specific layers.\r\n\r\nRelated Projects\r\n================\r\nWe list here some of the related projects and comment why they did not satisfy our requirements.\r\n\r\n* https://github.com/go-swagger/go-swagger produces code which looked a bit too clumsy for us.\r\n* https://github.com/swagger-api/swagger-codegen written in Java and hence hard for us to extend and customize.\r\n* https://grpc.io/ gRPC is great when remote procedure calls are all you need. However, it requires you to use HTTP 2,\r\n and we found it hard to integrate with widely-used browsers as clients.\r\n\r\n Additionally, streaming files was not directly supported (see https://github.com/grpc/grpc-go/issues/414).\r\n* https://github.com/grpc-ecosystem/grpc-gateway provides a JSON gateway to gRPC. We found that it added an additional\r\n layer of complexity (especially when the number of client/server pairs grow), and preferred to have a simple solution\r\n with a single code generation tool.\r\n* https://github.com/twitchtv/twirp a (better?) alternative if you only want to generate remote procedure calls based on\r\n JSON using protocol buffers to specify the API. It forces you to stick to its representation, though, and does not\r\n allow you to use an arbitrary Swagger specification. This is problematic when the interface is imposed on you from\r\n outside (*e.g.*, by customers).\r\n\r\nInstallation\r\n============\r\n\r\n* Create a virtual environment:\r\n\r\n.. code-block:: bash\r\n\r\n python3 -m venv venv3\r\n\r\n* Activate it:\r\n\r\n.. code-block:: bash\r\n\r\n source venv3/bin/activate\r\n\r\n* Install swagger_to with pip:\r\n\r\n.. code-block:: bash\r\n\r\n pip3 install swagger_to\r\n\r\nUsage\r\n=====\r\nTo generate code, you need to invoke one of the ``swagger_to_*.py`` scripts. If the generated code exists, you need to\r\nspecify ``--force`` command-line argument in order to overwrite the existing files.\r\n\r\nWe use the tag `name` to designate the generate code (*e.g.*, package name in the Go server or service name in the\r\nPython client code). See `this example <tests/cases/py_client/general/swagger.yaml#L10>`_ from the test cases.\r\n\r\nElm Client\r\n----------\r\nTo generate an Elm client from a Swagger specification at ``/some/path/swagger.yaml``, invoke:\r\n\r\n.. code-block:: bash\r\n\r\n swagger_to_elm_client.py \\\r\n --swagger_path /some/path/swagger.yaml \\\r\n --outdir /some/elm/path/src/your-client-directory\r\n\r\nThe generated code will have the following structure in ``/some/elm/path/src/your-client-directory``:\r\n\r\n=========================== ========================================================================================\r\nFile Description\r\n=========================== ========================================================================================\r\n``Client.elm`` Elm Client, containing Models, Encoders, Decoders and Http Requests.\r\n``elm-package.sample.json`` The Elm JSON Package containing the libraries used in Client.elm.\r\n=========================== ========================================================================================\r\n\r\nTwo non-standard libraries are used in the Client:\r\n\r\n* \"NoRedInk/elm-decode-pipeline\" is used to decode JSON objects in a more scalable way than the one supported by the\r\n elm-lang libraries; and\r\n* \"elm-community/json-extra\" is needed to encode Dict variables.\r\n\r\n\r\nWe use Elm's built-in Int type to represent both 32 and 64-bit integers. Please be careful: Elm depends on JavaScript\r\nwhich uses solely double-precision floats both for integers and for floating-point numbers, which can lead to\r\nunexpected truncation.\r\n\r\nGo Server\r\n---------\r\nTo generate a Go server from a Swagger specification at ``/some/path/swagger.yaml``, invoke:\r\n\r\n.. code-block:: bash\r\n\r\n swagger_to_go_server.py \\\r\n --swagger_path /some/path/swagger.yaml \\\r\n --outdir /some/go/path/src/your-server-package\r\n\r\nThe generated code will have the following structure in ``/some/go/path/src/your-server-package``:\r\n\r\n========================== ========================================================================================\r\nFile Description\r\n========================== ========================================================================================\r\n``types.go`` Go type definitions\r\n``jsonschemas.go`` JSON schemas used to validate the input (using https://github.com/xeipuuv/gojsonschema)\r\n``routes.go`` Router specification\r\n``handler.go`` Handler interface\r\n``handler_impl.sample.go`` Empty implementation of the handler\r\n========================== ========================================================================================\r\n\r\nAll the types defined in the Swagger are translated to ``types.go``. The routing and validation code around\r\nthe endpoints is generated in ``jsonschemas.go`` and ``routes.go``.\r\n\r\nThe handler interface is given in ``handler.go``. You need to implement the handler logic yourself. You can use\r\n``handler_impl.sample.go`` as a starting point. We usually just copy/paste it to ``handler_impl.go`` and ignore\r\n``handler_impl.sample.go`` in our repositories (*e.g.*, by adding it to ``.gitignore``).\r\n\r\nIn face of Swagger (*i.e.* API) changes, our workflow includes regenerating the code and using a diff tool\r\nlike ``meld`` to sync the \"old\" ``handler_impl.go`` with the new ``handler_impl.sample.go``.\r\n\r\nPecularities\r\n~~~~~~~~~~~~\r\n* **parameters**. We decided to generate the code to extract the parameters only from queries, bodies and paths.\r\n\r\n It seemed difficult to automatically generate the code to extract form data arguments which would cover all the edge\r\n cases (such as files and duplicate entries). We still generate the handler function, but leave it to the programmer\r\n to extract these arguments manually from the request.\r\n\r\n Due to lack of time, we did not implement header and cookie parameters. Contributions for these features are highly\r\n welcome!\r\n\r\n* **response**. The auto-generated code does not check that the response conforms to the specification. We found such\r\n checks to be unnecessarily constraining and almost impossible to implement for all the use cases.\r\n\r\n\r\nPython Client\r\n-------------\r\nTo generate a Python 3 client from a Swagger specification at ``/some/path/swagger.yaml``, invoke:\r\n\r\n.. code-block:: bash\r\n\r\n swagger_to_py_client.py \\\r\n --swagger_path /some/path/swagger.yaml \\\r\n --outpath /some/py/path/your_client_module.py\r\n\r\nThe generated client uses ``requests`` library.\r\n\r\nSince input checks need to be performed by the server anyhow, we decided not to keep the code generator simple and\r\nmore maintainable by including only the rudimentary type checks on the inputs. Hence all the sophisticated checks\r\nsuch as string patterns or casting of a Python integer to int32 are deliberately excluded. Analogously, we also\r\ndo not validate the output coming from the server.\r\n\r\nIf time ever permits, we would like to include both more fine-grained input and output validation. At the moment,\r\nwe did not confront any problems in the development process.\r\n\r\n\r\nTypescript+Angular Client\r\n-------------------------\r\nTo generate a Python client from a Swagger specification at ``/some/path/swagger.yaml``, invoke:\r\n\r\n.. code-block:: bash\r\n\r\n swagger_to_ts_angular5_client.py \\\r\n --swagger_path /some/path/swagger.yaml \\\r\n --outpath /some/typescript/path/your_client.ts\r\n\r\nThe generated client uses Angular ``http`` library. For the same reasons as for Python client, no checks are performed\r\nneither on the input nor on the output.\r\n\r\nWe use Typescript's built-in number type to represent both 32 and 64-bit integers. Please be careful: Typescript\r\ndepends on JavaScript which uses solely double-precision floats both for integers and for floating-point numbers,\r\nwhich can lead to unexpected truncation.\r\n\r\n\r\nStyle Check\r\n-----------\r\nWe found it important to have a uniform documentation style across all the Swagger specifications in an organization.\r\nTo that end, swagger_to includes an utility to automatically check the style such as casing of the definition names,\r\nproperty names, descriptions and verb moods (present tense instead of imperative).To check the compliance of a Swagger\r\nspecification at ``/some/path/swagger.yaml`` to the Swagger style guides, invoke:\r\n\r\n.. code-block:: bash\r\n\r\n swagger_style.py \\\r\n --swagger_path /some/path/swagger.yaml\r\n\r\n\r\nThe following checks are performed:\r\n\r\n* The Swagger name is in camel case, its description capitalized, and the base path starts with a slash.\r\n* Top level type definitions are in capitalized camel case, and properties are in snake case.\r\n* Endpoint paths, operation_id and parameter names are in camel case.\r\n* All descriptions:\r\n * start with a present tense verb, whose first letter is lower case;\r\n * have no leading or trailing whitespaces, tabs or new lines;\r\n * contain either one line, or three or more, in which case the second is empty;\r\n * end with a period.\r\n* Endpoint paths start with a slash, and the responses contain \"200\" and \"default\".\r\n\r\nThe script call returns 0 in case of no violations found, 1 in case of failed checks or 2 in case of illegal usage.\r\n\r\nExamples\r\n========\r\n\r\nYou can find the following examples useful for development:\r\n\r\n* Swagger API: https://github.com/Parquery/swagger-to/blob/master/tests/cases/go_server/general/swagger.yaml\r\n\r\n* Go Server generated code: https://github.com/Parquery/swagger-to/tree/master/tests/cases/go_server/general\r\n\r\n* Py Client generated code: https://github.com/Parquery/swagger-to/blob/master/tests/cases/py_client/general/client.py\r\n\r\n* Elm client generated code: https://github.com/Parquery/swagger-to/blob/master/tests/cases/elm_client/general/Client.elm\r\n\r\n\r\nDevelopment\r\n===========\r\n\r\n* Check out the repository.\r\n\r\n* In the repository root, create the virtual environment:\r\n\r\n.. code-block:: bash\r\n\r\n python3 -m venv venv3\r\n\r\n* Activate the virtual environment:\r\n\r\n.. code-block:: bash\r\n\r\n source venv3/bin/activate\r\n\r\n* Install the development dependencies:\r\n\r\n.. code-block:: bash\r\n\r\n pip3 install -e .[dev]\r\n\r\n* Run `precommit.py` to execute pre-commit checks locally.\r\n\r\nVersioning\r\n==========\r\nWe follow `Semantic Versioning <http://semver.org/spec/v1.0.0.html>`_. The version X.Y.Z indicates:\r\n\r\n* X is the major version (backward-incompatible),\r\n* Y is the minor version (backward-compatible), and\r\n* Z is the patch version (backward-compatible bug fix).\r\n\r\n\r\n",
"bugtrack_url": null,
"license": "License :: OSI Approved :: MIT License",
"summary": "Generate server and client code from Swagger (OpenAPI 2.0) specification",
"version": "5.0.1",
"split_keywords": [
"swagger",
"code",
"generation",
"python",
"elm",
"go",
"typescript",
"server",
"client",
"angular"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "3ee00bc07fa90a5d64c5cfd88845a313d9729af86c1c3d0e772bc8e3942e22ab",
"md5": "f896fecf5fdd310b763f5210797bf9ef",
"sha256": "cf0f0326e1e4cd89182cefd99b15cc5542037fefc8af3114fc9cd4195e2ee242"
},
"downloads": -1,
"filename": "swagger_to-5.0.1.tar.gz",
"has_sig": false,
"md5_digest": "f896fecf5fdd310b763f5210797bf9ef",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 62915,
"upload_time": "2023-01-27T11:26:10",
"upload_time_iso_8601": "2023-01-27T11:26:10.843476Z",
"url": "https://files.pythonhosted.org/packages/3e/e0/0bc07fa90a5d64c5cfd88845a313d9729af86c1c3d0e772bc8e3942e22ab/swagger_to-5.0.1.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2023-01-27 11:26:10",
"github": true,
"gitlab": false,
"bitbucket": false,
"github_user": "Parquery",
"github_project": "swagger-to",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"tox": true,
"lcname": "swagger-to"
}
JSON
