openapi-python-client
sphinx
openapi-python-client | sphinx | |
---|---|---|
6 | 31 | |
1,075 | 6,046 | |
3.9% | 1.1% | |
9.0 | 9.8 | |
8 days ago | 5 days ago | |
Python | Python | |
MIT License | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
openapi-python-client
-
GraphQL is for Backend Engineers
On the backend, developers either need to manually document the entire API or rely on auto-generation tools that don’t fully meet their needs. Consumers face the same choice, write code by hand or workaround the bugs in their SDK generator (stated, lovingly, as the maintainer of an OpenAPI client generator). On top of this, these solutions result in inconsistent understandings of the API. Reproducing errors becomes time-consuming and frustrating, which feels like a battle instead of a collaboration. What we need is a shared language to describe how the API works—one that doesn’t add unnecessary layers of abstraction or manual work.
-
Microsoft Kiota: CLI for generating an API client to call OpenAPI-described API
Has anyone tried Kiota, specifically the Python support? How does it compare to https://github.com/openapi-generators/openapi-python-client ?
-
Python toolkits
I think we use these - https://github.com/openapi-generators/openapi-python-client
-
YAML: It's Time to Move On
Thanks for the link, but not necessarily.
How WSDL and the code generation around it worked, was that you'd have a specification of the web API (much like OpenAPI attempts to do), which you could feed into any number of code generators, to get output code which has no coupling to the actual generator at runtime, whereas Pyotr is geared more towards validation and goes into the opposite direction: https://pyotr.readthedocs.io/en/latest/client/
The best analogy that i can think of is how you can also do schema first application development - you do your SQL migrations (ideally in an automated way as well) and then just run a command locally to generate all of the data access classes and/or models for your database tables within your application. That way, you save your time for 80% of the boring and repetitive stuff while minimizing the risks of human error and inconsistencies, while nothing preventing you from altering the generated code if you have specific needs (outside of needing to make it non overrideable, for example, a child class of a generated class). Of course, there's no reason why this can't be applied to server code either - write the spec first and generate stubs for endpoints that you'll just fill out.
Similarly there shouldn't be a need for a special client to generate stubs for OpenAPI, the closest that Python in particular has for now is this https://github.com/openapi-generators/openapi-python-client
However, for some reason, model driven development never really took off, outside of niche frameworks, like JHipster: https://www.jhipster.tech/
Furthermore, for whatever reason formal specs for REST APIs also never really got popular and aren't regarded as the standard, which to me seems silly: every bit of client code that you write will need a specific version to work against, which should be formalized.
-
Replacing FastAPI with Rust: Part 2 - Research
Tallying up the results, we get 7/8 "MUST" requirements met. I think that Paperclip + actix-web seems like the most promising candidate. I'm really not opposed to writing the OpenAPI v3 construction myself as I've worked with the structure a fair bit in my openapi-python-client project (shameless plug).
-
Replacing FastAPI with Rust: Part 1 - Intro
Automatic documentation via OpenAPI, which lets you do things like generate Python code that knows how to talk to your API.
sphinx
-
5 Best Static Site Generators in Python
Sphinx is primarily known as a documentation generator, but it can also be used to create static websites. It excels in generating technical documentation, and its support for multiple output formats, including HTML and PDF, makes it a versatile tool. Sphinx uses reStructuredText for content creation and is highly extensible through plugins.
-
User Guides in Code Documentation: Empowering Users with Usage Instructions
Sphinx a documentation generator or a tool that translates a set of plain text source files into various output formats, automatically producing cross-references, indices, etc. That is, if you have a directory containing a bunch of reStructuredText or Markdown documents, Sphinx can generate a series of HTML files, a PDF file (via LaTeX), man pages and much more.
-
MdBook – Create book from Markdown files. Like Gitbook but implemented in Rust
Notable mentions to [Sphinx](https://www.sphinx-doc.org/). It's workflow is more tuned to the "book" format rather than the blog, forum or thread format.
-
best packages for documenting the flow of logic?
Currently trying out Sphinx (https://www.sphinx-doc.org) and the trying to get the autodocgen feature to see what that can do.
-
Generate PDF from file (docstrings)
So, I've documented my code and now I need a .PDF with this documentation. Is there any easy way to do it? Once I used Sphinx but it generated a not so easy .TeX.
-
Introducing AutoPyTabs: Automatically generate code examples for different Python versions in MkDocs or Sphinx based documentations
AutoPyTabs allows you to write code examples in your documentation targeting a single version of Python and then generates examples targeting higher Python versions on the fly, presenting them in tabs, using popular tabs extensions. This all comes packaged as a markdown extension, MkDocs plugin and a Sphinx, so it can easily be integrated with your documentation workflow.
-
dictf - An extended Python dict implementation that supports multiple key selection with a pretty syntax.
Honestly, I think it's just an issue of documentation. For example, if there was an easier way to document @overload functions, that would help (cf. https://github.com/sphinx-doc/sphinx/issues/7787)
-
Pipeline documentation
We use sphynx for our pipeline documentation for all technical details Classes , packages and functions docstrings using reStructuredText (reST) format
-
Minimum Viable Hugo – No CSS, no JavaScript, 1 static HTML page to start you off
I like Sphinx [0] with the MyST Markdown syntax [1]. There is a related project, Myst NB [2], which enables including Jupyter notebooks in your site. There is also a plugin for blogging [3].
[0]: https://www.sphinx-doc.org
-
Marketing for Developers
Sphinx is the go-to tool for documentation. It took me a while to understand how to use Sphinx, but I now have a decent workflow with MyST which allows me to write all the docs in markdown. My sphinx-markdown-docs repo shows an example of what I do.
What are some alternatives?
sqlx - 🧰 The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, and SQLite.
MkDocs - Project documentation with Markdown.
starlark - Starlark Language
pdoc - API Documentation for Python Projects
paperclip - WIP OpenAPI tooling for Rust. [Moved to: https://github.com/paperclip-rs/paperclip]
Pycco - Literate-style documentation generator.
okapi - OpenAPI (AKA Swagger) document generation for Rust projects
fastapi - FastAPI framework, high performance, easy to learn, fast to code, ready for production
warp - A super-easy, composable, web server framework for warp speeds.
mkdocs-material - Documentation that simply works
yaml-reference-parser
Python Cheatsheet - All-inclusive Python cheatsheet