resolve typing errors in project after merge

[Andrew Omondi (andrueastman)]

Partial of #302

Resolves failing mypy issues after repositories merging.

In general

• Methods return and parameter types were inconstent across the inheritance hierachy

CI for the PR at https://github.com/microsoft/kiota-abstractions-python/actions/runs/10807820407

[Vincent Biret (baywet)]

overall this is great as it uncovers a bunch of defects in the type declarations.
I'm a bit worried about the blast radius for anybody relying on static type checking? (I know not everyone does that in Python)

[Andrew Omondi (andrueastman)]

I'm a bit worried about the blast radius for anybody relying on static type checking? (I know not everyone does that in Python)

Thanks for taking a look Vincent Biret (@baywet). I do also have a similar concern but feel like having the typing correct would be place we want to be at. e.g. There are some scenarios uncovered with implementations with more params than the parent class interface.

What I can probably do as well is also do something similar to TS and generate a test project with Kiota and see what that uncovers as well. https://github.com/microsoft/kiota-typescript/tree/main/packages/test

This will help understand if changes here are a big break.

I'll set this as draft in the meantime to set that up if that makes sense.

[Vincent Biret (baywet)]

yes, having a smoke client with static type checking would help I believe.

[Andrew Omondi (andrueastman)]

Created #333 to resolve parsable generation typing issues.

[Andrew Omondi (andrueastman)]

Vincent Biret (@baywet)
microsoft/kiota#5453 should resolve generation gaps while #340 should add a test project and fix gaps in the libs.

Once those are closed, and this is good to go, I believe we can merge this one and now simply sort out the workflows to merge the repositories.

[Vincent Biret (baywet)]

Thanks for the follow up here.
What I'd like a clear answer on is the following: are these changes going to break builds for people with existing clients if they don't refresh the generated code?

[Andrew Omondi (andrueastman)]

The short answer is not really. Builds are already broken(for users who try to consume the typing info of our packages) as we were really not publishing the typing information.

The error/warning that shows up for current packages looks something like this.

Skipping analyzing "kiota_serialization_form.form_parse_node_factory": module is installed, but missing library stubs or py.typed marker [import-untyped]

According to PEP 561, for the type information to be consumed downstream, a package author either

• MUST add a marker file named py.typed to their package supporting typing
• Publish a separate stub only package with the type information

If you take a look at the sources, none of them specify a py.typed marker(and we definitely don't publish a separate stub package).

• Abstractions
• Auth
• Http
• Serialization json
• Serialization text
• Serialization multipart

What this means then is that for the consumer, currently, they would either

• Write their own stub files
• Suppress the error of missing types by passing the ignore_missing_imports = True to the checker so that 3rd party packages that are not PEP 561 compliant are ignored.

From the sources, it looks like we have been also suppressing type validation across projects and this explains why the typing issues discovered here were not surfacing across projects. See examples below (but this is across all projects)

• https://github.com/microsoft/kiota-serialization-multipart-python/blob/211057c8c0d9e10283009eadde63a16d374060e5/pyproject.toml#L36
• https://github.com/microsoft/kiota-abstractions-python/blob/c2d52b504f0a283e906bd6f756a21ab52b406fa1/pyproject.toml#L38
• https://github.com/microsoft/kiota-serialization-json-python/blob/51189ef48a8e298c691025bb6d426b4b0d40f0c7/pyproject.toml#L36

As we are moving to a mono repo structure, the packages do not see each other as 3rd party anymore as they are co-located and thus the suppression won't hide these type errors anymore. So, if we wish to keep the type checking we would need to fix them.

The end result of this process then will be

• Our packages will be PEP 561 compliant(as we have added the py.typed markers in this PR and Merge sources into one repo #329) so the typing information will consumed downstream.(no need for supressions when consuming packages)
• Typing information will be correct (validated with the generated client)

Hope this makes things clearer.

[Vincent Biret (baywet)]

Thank you so much for diving into this! We're effectively cleaning up a lot of defects in the types (or absence of) as the library as published. I guess some people might start seeing new errors surfacing up as the type system will kick in, but with this level of details it should be easy to justify we're actually fixing a major feature of kiota python clients.

I'm guessing the graph packages are also missing the proper metadata at this stage?

[sonarqubecloud]

Quality Gate failed

Failed conditions
35.8% Duplication on New Code (required ≤ 3%)

See analysis details on SonarCloud

[Vincent Biret (baywet)]

Andrew Omondi (@andrueastman) as a side note, this PR will also need to be replicated here microsoft/kiota-serialization-json-python#369

[Andrew Omondi (andrueastman)]

ft/kiota-serialization-json-python#369

Thanks for highlighting this Vincent Biret (@baywet)

I've added this as a task in the bigger PR at #329 so that we try close this and not mix too many concerns here. I'll create a separate PR into the bigger PR once this one is closed.

[Vincent Biret (baywet)]

Thank you for making the changes!