-
-
Notifications
You must be signed in to change notification settings - Fork 361
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: metadata parsing #3308
Draft
peterschutt
wants to merge
18
commits into
v3.0
Choose a base branch
from
metadata-parsing
base: v3.0
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In some cases, I've wanted to change the name of the "Application" to show something else instead of "Litestar". This is usually to make a CLI feel more cohesive and part of a larger application. In the same vein, I've found cases where I wanted to complete suppress the initial `from_env` or the Rich info table at startup.
--------- Co-authored-by: Janek Nouvertné <25355197 [email protected]> Co-authored-by: Jacob Coffee <[email protected]>
* refactor: openapi router This PR refactors the way that we support multiple UIs for OpenAPI. We add `litestar.openapi.plugins` where `OpenAPIRenderPlugin` is defined, and implementations of that plugin for the frameworks we currently support. We add `OpenAPIConfig.render_plugins` config option, where a user can explicitly declare a set of plugins for UIs they wish to support. If a user declares a sub-class of `OpenAPIController` at `OpenAPIConfig.openapi_controller`, then existing behavior is preserved exactly. However, if no controller is explicitly declared, we invoke the new router-based approach, which should behave identically to the controller based approach (i.e., respect `enabled_endpoints` and `root_schema_site`). Closes #2541 * docs: start of documentation re-write. - creates an indexed directory for openapi - removes the controller docs - start of docs for plugins * refactor: move JsonRenderPlugin into private ns We add the json plugin, and have hardcoded refs to the path that it serves, so best not to make this public API just yet. * docs: reference docs for plugins * Revert "refactor: move JsonRenderPlugin into private ns" This reverts commit 60719aa. * docs: JsonRenderPlugin undocumented. * docs: continue plugin docs * test: run tests for both plugin and controller Modifies tests where appropriate to run on both the plugin-based approach and the controller based approach. * Implement default endpoint selection logic. * Deprecation of OpenAPIController configs * docs: swagger oauth examples * Update docs/usage/openapi/ui_plugins.rst * Update docs/usage/openapi/ui_plugins.rst * fix: linting * refactor: don't rely on DI for openapi schema in plugin handler. * fix(test): there's an extra schema route to serve 404s. * fix(docs): docstring indent * fix(lint): remove redundant return * refactor: plugins receive style tag instead of tag content. * feat: allow openapi router to be handed to openapi config. Allows for customization, such as adding guards, middleware, other routes, etc. * feat: add `scalar` schema ui (#2906) * Update litestar/openapi/plugins.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/openapi/plugins.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/openapi/plugins.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/openapi/config.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/openapi/config.py Co-authored-by: Jacob Coffee <[email protected]> * fix: update deprecation version * fix: use GH repo for scalar links * fix: update default scalar version * fix: scalar plugin style attribute render. Plugins expect that the style value is already wrapped in `<style>` tags. * fix: serve default static files via jsdeliver * fix: docstring syntax * fix: removes custom repr Can always add if there's a need for it, but we aren't using it. * docs: another pass * fix: style * fix: test for updated build openapi plugin example * fix: absolute paths for openapi.json Resolves #3047 for the openapi router case. * refactor: simplify scalar plugin. * fix: linting * Update litestar/_openapi/plugin.py * refactor: test app to use scalar ui plugin * fix: plugin customization example Version arg is ignored if `js_url` is provided. * fix: remove unnecessary kwargs Removes passing default values to plugin kwargs in examples. * fix: grammar error * feat: make OpenAPIRenderPlugin an ABC Abstract on `render()` method. * fix: correct referenced lines Referenced LoC in example had drifted. * fix: more small docs corrections * chore: remove dup spec of enabled endpoints. * fix: simplify test. --------- Co-authored-by: Jacob Coffee <[email protected]>
* Enable DTO codegen backend by default * Update docs
* feat: Added precedence of CLI parameters over envs * Update docs/usage/cli.rst Co-authored-by: Peter Schutt <[email protected]> * Remove redundant LitestarEnv fields and fix tests * Update docs/usage/cli.rst * Update litestar/cli/commands/core.py * Update docs/usage/cli.rst * Update docs/usage/cli.rst * Update litestar/cli/commands/core.py --------- Co-authored-by: kedod <kedod> Co-authored-by: Peter Schutt <[email protected]> Co-authored-by: Jacob Coffee <[email protected]>
* feat: Support `schema_extra` in `Parameter` and `Body` (#3022) This adds sort of a backdoor for modifying the generated OpenAPI spec. The value is given as `dict[str, Any]` where the key must match with the keyword parameter name in `Schema`. The values are used to override items in the generated `Schema` object, so they must be in correct types (ie. not in dictionary/json format). The values are added at main level, without recursive merging (because we're adjusting `Schema` object and not a dictionary). Recursive merge would be much more work. Chose not to implement the same for `ResponseSpec` because response models are generated as schema components, while `ResponseSpec` can be locally different. Handling the logic of creating new components when `schema_extra` is passed in `ResponseSpec` would be extra effort, and isn't probably as important as being able to adjust the inbound parameters, which are actually validated (and for which the documentation is even more important, than for the response). * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> * Update litestar/params.py Co-authored-by: Jacob Coffee <[email protected]> --------- Co-authored-by: Jacob Coffee <[email protected]>
Adds deprecated directives for the deprecated parameters of the config. Adds some cross-references.
* adding draft for security exclusion docs * adding section to security toctree * Update docs/usage/security/excluding-and-including-endpoints.rst * Update docs/usage/security/excluding-and-including-endpoints.rst * Update docs/usage/security/excluding-and-including-endpoints.rst --------- Co-authored-by: Jacob Coffee <[email protected]>
* feat: Add LITESTAR_ prefix for web concurrency env option * Replace depacrated with versionchanged directive * Change wc option description * Remove depracation warning --------- Co-authored-by: kedod <kedod>
This PR aims to change our approach of parsing schema metadata from an indiscriminate ducktype approach to a deliberate approach with situational awareness. For parameter declarations, we should only parse schema metadata from instances of `KwargDefinition` and sub-types. For model parsing, including dataclasses, typeddict and 3rd party modelling libraries, we should only parse metadata according to that modelling libraries supported methods of constraint delivery. For #3202
peterschutt
force-pushed
the
metadata-parsing
branch
from
April 3, 2024 23:36
39a4436
to
8a87153
Compare
provinzkraut
force-pushed
the
v3.0
branch
3 times, most recently
from
April 27, 2024 07:15
c517c0b
to
2536957
Compare
provinzkraut
force-pushed
the
v3.0
branch
2 times, most recently
from
April 28, 2024 11:19
81081dd
to
a4d7ea1
Compare
provinzkraut
force-pushed
the
v3.0
branch
2 times, most recently
from
May 26, 2024 07:39
4dc78a8
to
81a323f
Compare
provinzkraut
force-pushed
the
v3.0
branch
2 times, most recently
from
June 16, 2024 07:50
42bf08f
to
981ea94
Compare
provinzkraut
force-pushed
the
v3.0
branch
3 times, most recently
from
August 28, 2024 16:32
8df1b17
to
33ded66
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As spoken about in discord recently, the objective of the
litestar.typing
module was to have a simple interface to represent types. However, a lot of logic to do with schema constraint parsing has made its way in there, which has been the source of many bugs and hard to follow logic. This bit me again today as the root of a circular import problem.This PR attempts to move metadata parsing to where it is needed, and where it has the context of the library/framework from where the metadata originates.
WIP - not sure if feasible, but lets see.
Description
Closes