starlark
openapi-python-client
Our great sponsors
starlark | openapi-python-client | |
---|---|---|
22 | 6 | |
2,221 | 1,066 | |
2.7% | 6.8% | |
4.5 | 9.0 | |
about 2 months ago | 3 days ago | |
Starlark | Python | |
Apache License 2.0 | MIT License |
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.
starlark
- (The) Starlark Language
-
Apple releases Pkl – onfiguration as code language
The implementations and users page mentioned above:
https://github.com/bazelbuild/starlark/blob/master/users.md
- Language design of Starlark (compared to Python)
-
10 Ways for Kubernetes Declarative Configuration Management
Starlark: Starlark is a language for describing build transformations, inspired by Python, but with features that make it suitable for embedding in software like Bazel. It can be used for configuration generation due to its capability for deterministic evaluation and expressing complex build transformations.
-
How Big Should a Programming Language Be?
In the design of Starlark (https://github.com/bazelbuild/starlark), I often had to push back against new feature requests to keep the language simple. I explicitly listed simplicity as a design goal.i
Of course, the scope of the language is not the same as general purpose languages, but there's always pressure from the users to add more things. I also think many people underestimate the cost of adding new features: it's not just about adding the code in every compiler/interpreter, specifying every edge-case in a spec, updating all the tooling for the language and writing tutorials; it's also a cost on everyone who will have to read any of the code.
-
Launch HN: Moonrepo (YC W23) – Open-source build system
one of the benefits of starlark (unlike python): "Starlark is suitable for use in highly parallel applications. An application may invoke the Starlark interpreter concurrently from many threads, without the possibility of a data race, because shared data structures become immutable due to freezing." from https://github.com/bazelbuild/starlark/blob/master/spec.md - it's not python, you can't do recursion (!) and it's more limited (you can't read a file in bazel, and parse it, you have to make this operation into the graph somehow)
-
When to use Bazel?
You can do the same in Bazel which uses Starlark for its BUILD files. Starlark is a dialect of Python so it makes it super easy to work with.
-
[P] Docker alternative for AI/ML
Make sense. We do not use Python actually, the build language is starlark, which is the config lang used by bazel. https://github.com/bazelbuild/starlark
-
The Dhall Configuration Language
Have you seen Starlark? It's not too far from that, but safer in a number of ways: https://github.com/bazelbuild/starlark
- What change should Python 4 bring, in your opinion?
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.
What are some alternatives?
yaml-reference-parser
sqlx - 🧰 The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, and SQLite.
dhall - Maintainable configuration files
paperclip - WIP OpenAPI tooling for Rust. [Moved to: https://github.com/paperclip-rs/paperclip]
dhall-kubernetes - Typecheck, template and modularize your Kubernetes definitions with Dhall
okapi - OpenAPI (AKA Swagger) document generation for Rust projects
starlark-go - Starlark in Go: the Starlark configuration language, implemented in Go
warp - A super-easy, composable, web server framework for warp speeds.
cdk8s - Define Kubernetes native apps and abstractions using object-oriented programming
VecStack - A stack-based language for drawing vector graphics
JHipster - JHipster, much like Spring initializr, is a generator to create a boilerplate backend application, but also with an integrated front end implementation in React, Vue or Angular. In their own words, it "Is a development platform to quickly generate, develop, & deploy modern web applications & microservice architectures."