Находки в опенсорсе: Python

Помните про https://github.com/ozeranskii/httptap?

Я писал о нем давно еще - > тут.

Наклепал много issue, для тех кто хочет вкатиться в OSS или попрактиковаться себя и свою LLM - welcome. Только, пожалуйста, без нейрослопа и не будьте meat-proxy. Не хочу тратить время на фиксы фиксов. Ибо вот даже простой фикс, я исправил (смотри историю коммитов в PR), так как почитал документацию, а автор видимо нет.

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 `test_custom_union_format` failed in CI (#1533)


Seed for the repro: --randomly-seed=1177358910

FAILED tests/test_unit/test_plugins/test_pydantic/test_pydantic_schema.py::test_custom_union_format[PydanticSerializer] - AssertionError: assert Schema(all_of...ne, defs=None) == Schema(all_of...ne, defs=None)
  
  Omitting 58 identical items, use -vv to show
  Differing attributes:
  ['type']
  
  Drill down into differing attribute type:
    type: [<OpenAPIType.STRING: 'string'>, <OpenAPIType.INTEGER: 'integer'>] != [<OpenAPIType.INTEGER: 'integer'>, <OpenAPIType.STRING: 'string'>]
    At index 0 diff: <OpenAPIType.STRING: 'string'> != <OpenAPIType.INTEGER: 'integer'>
    
    Full diff:
      [
    +     <OpenAPIType.STRING: 'string'>,
          <OpenAPIType.INTEGER: 'integer'>,
    -     <OpenAPIType.STRING: 'string'>,
      ]
FAILED tests/test_unit/test_plugins/test_pydantic/test_pydantic_schema.py::test_custom_union_format[PydanticFastSerializer] - AssertionError: assert Schema(all_of...ne, defs=None) == Schema(all_of...ne, defs=None)
  
  Omitting 58 identical items, use -vv to show
  Differing attributes:
  ['type']
  
  Drill down into differing attribute type:
    type: [<OpenAPIType.STRING: 'string'>, <OpenAPIType.INTEGER: 'integer'>] != [<OpenAPIType.INTEGER: 'integer'>, <OpenAPIType.STRING: 'string'>]
    At index 0 diff: <OpenAPIType.STRING: 'string'> != <OpenAPIType.INTEGER: 'integer'>
    
    Full diff:
      [
    +     <OpenAPIType.STRING: 'string'>,
          <OpenAPIType.INTEGER: 'integer'>,
    -     <OpenAPIType.STRING: 'string'>,
      ]

https://github.com/wemake-services/django-modern-rest/actions/runs/34912494319/job/104202853421?pr=1510


#bug #help_wanted #ci #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @milssky
📝 Changes in benchmarking (#1505)


While working toward #207, I ran into the need for reliable benchmarking. We currently have four workers benchmarked using ab, which does not properly support HTTP/1.1. In particular, ab turns out to handle the -k flag incorrectly: it sends HTTP/1.0 requests with a Connection: Keep-Alive header, and different servers handle these requests differently. As a result, Uvicorn and Granian are effectively being tested under different conditions.

Furthermore, when multiple workers are used, the benchmark measures more than just the performance of the request-response lifecycle. The load generator creates a limited number of TCP connections, which the operating system distributes among the worker processes. Each keep-alive connection then remains bound to a single worker. This distribution may be uneven and can vary between runs, significantly affecting the resulting RPS.

Therefore, the current results cannot be used to evaluate the impact of individual parts of Django or a future RSGI implementation.

I see two possible approaches:

1. Fix the existing benchmark:
 • replace ab with a load generator that properly supports HTTP/1.1, such as hey;
 • run all servers with a single worker;
 • add Granian running in ASGI mode and soon add Granian in RSGO mode;
 • use the same concurrency level, duration, and other parameters for every server.
2. Keep the existing benchmark unchanged and add a separate benchmark for the request-response lifecycle:
 • use a single worker for Uvicorn, Granian, and Gunicorn;
 • use hey as the primary load generator;
 • run all servers under identical conditions;

Let’s discuss which direction we should take.


#feature #help_wanted #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Fix `operation_id` default generation rules (#1500)


Currently it produces: getAuthedandcookiescontrollerApiCookies for _AuthedAndCookiesController, see

django-modern-rest/tests/test_unit/test_plugins/test_msgspec/test_msgspec_snapshots.py

Lines 61 to 81 in f822e35

It must produce: getAuthedAndCookiesControllerApiCookies
Please, update all existing snapshots.


#bug #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Fix unused `security` field in `EndpointMetadata` and `_BasePayload` (#1499)


We don't use these two things:

1. security field documentation here:

 django-modern-rest/dmr/metadata.py

 Lines 429 to 430 in f822e35

2. django-modern-rest/dmr/validation/payload.py

 Line 44 in f822e35

However, I don't think that this is right. Users must have an option to configure this directly.
Let's create this rule:

• Any user provided security objects must be saved to the metadata
• It must be merged with explicit auth= providers

It might be useful when people define some external security mechanims, for example that work on HTTP proxy level, or in other microservices.

New snapshot test is required for this change.


#bug #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Test explicit `OpenAPIConfig.security` definition with `auth=None` per-endpoint (#1497)


Looks like we have a potential bug in how we define security in OpenAPI.
Here we always return None:

django-modern-rest/dmr/openapi/generators/security_scheme.py

Lines 24 to 37 in f822e35

But, if per-document security is set, we need to return [] as the value. Otherwise, None won't be dumped by our None-ignoring dump_schema rules. And security rules per this endpoint will be inherited from the document.

Which is wrong.

This would require a test and a fix. Maybe we should look at current config's security to define the return type?


#bug #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Test that nested URL patterns produce correct parameters (#1496)


We need to test a case like:

Router('tenants/<int:tenant_id>/', [path('users/<int:pk>/', MyController.as_view())])

It might contain a bug: we should get two path parameters, not one.


#good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 It is possible to produce an empty `description` for `ResponseBody` (#1495)


django-modern-rest/dmr/openapi/generators/component_parsers.py

Lines 193 to 199 in f822e35

It misses or None part. Because we only skip None values from dumping.


#bug #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Test and document that default values for components are supported (#1494)


Currently we don't ever test or document that a code like this:

from dmr import Body, Controller
from dmr.plugins.pydantic import PydanticSerializer


class MyController(Controller[PydanticSerializer]):
    def post(
        self,
        parsed_body: Body[dict[str, str] | None] = None,
    ) -> str:
        print(parsed_body)
        return 'done'

is even supported.

What is important here?

1. We must call the endpoint function as-is, without any work from our part. Defaults must be real python defaults. And work the same way
2. But, if there are default for Body, we must issue required: false schema for the whole body

Snapshot test is required for this change.


#good_first_issue #help_wanted #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Change how we work with `FileMetadata` validation (#1493)


Currently, this code is allowed:

from typing import Literal

import pydantic

from dmr import Body, Controller, FileMetadata
from dmr.plugins.pydantic import PydanticSerializer
from dmr.parsers import JsonParser, MultiPartParser


class Text(pydantic.BaseModel):
    content_type: Literal['text/plain']


class Files(pydantic.BaseModel):
    text: Text


class MyController(Controller[PydanticSerializer]):
    parsers = [JsonParser(), MultiPartParser()]

    def post(
        self,
        parsed_body: Body[dict[str, str]],
        parsed_file_metadata: FileMetadata[Files],
    ) -> str:
        return 'done'

But, how can we ever satisfy?

• JsonParser()
• parsed_file_metadata: FileMetadata[Files]

It is not optional. Every request here will fail.
What we can do? Change

django-modern-rest/dmr/components.py

Lines 866 to 889 in f822e35

from any to all.


#bug #good_first_issue #help_wanted #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Fix `Reference | Schema` conflict in our OpenAPI definitions (#1491)


Currently we mix up two different things in the code: Schema with $ref set and a Reference object with $ref set.

For example, this code:

import pydantic
from pydantic.json_schema import GenerateJsonSchema
from dmr.openapi.mappers.schema_loader import load_schema


class WithDialect(GenerateJsonSchema):
    def generate(self, schema, mode='validation'):
        json_schema = super().generate(schema, mode=mode)
        json_schema['$schema'] = self.schema_dialect
        return json_schema


class Address(pydantic.BaseModel):
    model_config = pydantic.ConfigDict(
        json_schema_extra={'$anchor': 'address', '$comment': 'Postal address'},
    )
    city: str


class User(pydantic.BaseModel):
    model_config = pydantic.ConfigDict(
        json_schema_extra={'$comment': 'Internal note for schema readers'},
    )
    name: str = pydantic.Field(json_schema_extra={'$comment': 'Display name'})
    address: Address = pydantic.Field(
        default=Address(city='Moscow'),
        description='Where the user lives',
    )


raw = pydantic.TypeAdapter(User).json_schema(
    ref_template='#/components/schemas/{model}',
    schema_generator=WithDialect,
)
defs = raw.pop('$defs')

Produces this schema:

{
  "$comment": "Internal note for schema readers",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "properties": {
    "name": {"$comment": "Display name", "title": "Name", "type": "string"},
    "address": {
      "$ref": "#/components/schemas/Address",
      "default": {"city": "Moscow"},
      "description": "Where the user lives"
    }
  },
  "required": ["name"], "title": "User", "type": "object"
}

But, we would load it as Reference object in load_schema and we will loose default and description. Which are Schema object attributes.

So, what we need to do?

1. Analyze all places where Reference can't be even used based on https://spec.openapis.org/oas/v3.2.0.html We need to grep this page with | Reference Object and check that we don't have more places that can hold Reference objects
2. We must distinguish $ref in potential Schema objects and Reference objects
3. We must change how our maybe_resolve_reference works to also resolve $ref in Schema objects, where we need it. Maybe we create a new type ResolvedSchema and use it in places where we expect flat schemas, so we won't forget to call maybe_resolve_reference

#bug #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Fix missing `Schema` attributes in `load_schema` (#1490)


In my personal opinion load_schema is the ugliest part of the framework. New issues proposing better design of this feature is MASSIVELY welcome. But, before that we need to fix the existing problem.

Here's how a schema is loaded right now:

django-modern-rest/dmr/openapi/mappers/schema_loader.py

Lines 67 to 127 in f822e35

We never set: anchor, comment, ref, and schema_uri. Maybe others?

But, $ref is the most complex one here. Please, ignore it for now, we must fix our Reference | Schema handling in all places at once 😢


#bug #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Support custom `format` options, add more pre-defined formats (#1489)


Currently we only allow format strings that are present in OpenAPIFormat enum. Which is not correct, because format is an open str type. Users can create custom formats. See the spec: https://spec.openapis.org/oas/v3.2.0.html#data-type-format

Also, add all formats from https://spec.openapis.org/registry/format/ to OpenAPIFormat just for the usability.

Also, please make sure that these types work correctly in tests/test_unit/test_plugins/test_pydantic/test_pydantic_snapshots.py:

• pydantic.NameEmail
• pydantic.Base64Str
• pydantic.Base64Bytes
• Custom format with json_schema_extra={'custom-format': ...} for regular str field in pydantic

#bug #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Make sure that `SecuritySchemeRegistry` can't re-register existing auth schemes (#1488)


Currently SecuritySchemeRegistry does not protect from registerting two auth schemes with the same name:

django-modern-rest/dmr/openapi/core/registry.py

Lines 127 to 142 in f822e35

This needs to be fixed. It must raise an error, no error must pass silently.


#bug #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Make `ConfigMerge` class customizable (#1487)


Currently, there's no way to customize the ConfigMerger class here:

django-modern-rest/dmr/openapi/core/context.py

Lines 61 to 69 in f822e35

This goes against our design, where we provide all classes as ClassVar[type[ConfigMerger]] objects.

It should be:

class OpenAPIContext:
     config_merger_cls: ClassVar[type[ConfigMerger]] = ConfigMerger

     # then:
     # self.config_merger = self.config_merger_cls(self)

#feature #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 `OpenAPI.json_schema_dialect` is never set (#1486)


We must add json_schema_dialect to OpenAPIConfig, because currently there's no way to set json_schema_dialect attribute.


#feature #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Support missing OpenAPI 3.2 features (#1485)



#feature #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator

🚀 New issue to ag2ai/faststream by @Lancetnik
📝 Bug: `StreamSub` warns that `no_ack` has no effect with a consumer group, but the flag is forwarded to XREADGROUP NOACK (#3126)


Describe the bug

StreamSub(..., group=..., consumer=..., no_ack=True) emits

RuntimeWarning: `no_ack` has no effect with consumer group

but the flag does have an effect: it reaches Redis as XREADGROUP ... NOACK, so entries never enter the PEL. The warning is a leftover from a time when the flag was not forwarded.

How to reproduce

from faststream.redis import RedisBroker, StreamSub

broker = RedisBroker()


@broker.subscriber(
    stream=StreamSub("my-stream", group="my-group", consumer="c1", no_ack=True),
)
async def handler(msg: str) -> None:
    ...

Constructing the StreamSub prints the warning. Running the app shows that the flag is honoured anyway: XPENDING my-stream my-group stays empty after messages are consumed.

Expected behavior

No warning. no_ack=True with a consumer group is a supported, documented mode ("equivalent to acknowledging the message when it is read", see docs/docs/en/redis/streams/groups.md).

Observed behavior

The warning is emitted in faststream/redis/schemas/stream_sub.py (the elif no_ack: branch under if group and consumer:), while the rest of the code base treats the flag as live:

• faststream/redis/subscriber/usecases/stream_subscriber.py passes noack=stream.no_ack to XREADGROUP;
• faststream/redis/subscriber/config.py switches the subscriber to AckPolicy.MANUAL when no_ack is set;
• faststream/redis/testing.py skips the PEL for no_ack subscribers;
• #3049 added a SetupError for claim_min_idle_time + no_ack, which only makes sense if no_ack works with groups.

History

• The warning was introduced in 0.3.5 (#1048), when no_ack was indeed not forwarded to XREADGROUP.
• #2309 kept the warning and reset no_ack = False right after it, so the flag really was ignored for a while.
• 0.6.0 (#1779) dropped that reset, and noack=stream.no_ack has been sent to Redis since, but the warning stayed.

The sibling warning, "no_ack is not supported by consumer group with last_id other than >", is a separate case and should be checked on its own: Redis documents NOACK for XREADGROUP regardless of the id, so it may be stale too.

Suggested fix

Remove the elif no_ack: warning branch in StreamSub.__init__ and add a test asserting that StreamSub("s", group="g", consumer="c", no_ack=True) raises no warning and that the subscriber calls xreadgroup with noack=True. Keep the claim_min_idle_time + no_ack SetupError as is.

Environment

Reproduced on main (commit 0307f09).


#bug #good_first_issue #redis #faststream #ag2ai
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Support better schema generation parameters (#1462)


Currently we don't pass quite a lot of options to both pydantic and msgspec schema generation:

django-modern-rest/dmr/plugins/pydantic/schema.py

Lines 27 to 30 in 405ba9b

When pydantic defines this method as:

def json_schema(
    self,
    *,
    by_alias: bool = True,
    ref_template: str = DEFAULT_REF_TEMPLATE,
    union_format: Literal['any_of', 'primitive_type_array'] = 'any_of',
    schema_generator: type[GenerateJsonSchema] = GenerateJsonSchema,
    mode: JsonSchemaMode = 'validation',
) -> dict[str, Any]:

The same with msgspec:

django-modern-rest/dmr/plugins/msgspec/schema.py

Lines 24 to 27 in 405ba9b

Signature:

def schema(
    type: Any,
    *,
    schema_hook: Optional[Callable[[type], dict[str, Any]]] = None,
    ref_template: str = _REF_TEMPLATE,
) -> dict[str, Any]:

So, what we need to do:

1. Provide way to easily customize the schema generation for both pydantic and msgspec
2. Both would have different API, matching the current defaults
3. Document how to customize the schema generation this way: create your own serializer, subclass schema generator, use it
4. Add tests for 2 of these cases, especially with custom schema_hook and schema_generator options

#feature #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator

🚀 New issue to wemake-services/django-modern-rest by @sobolevn
📝 Make sure that it is possible to customize `operation_id` generation (#1461)


If people need to tailor the operation_id exact look, we need to be able to provide a callback to do that.

I think that we need to do it somewhere here:

• django-modern-rest/dmr/openapi/core/context.py

 Line 29 in 405ba9b

• django-modern-rest/dmr/openapi/core/context.py

 Line 80 in 405ba9b

Probably via a callback? Other options are also fine :)
But, make sure that the default implementation will be kept.


#feature #good_first_issue #help_wanted #openapi #opensource_september #django_modern_rest
sent via relator