Skip to content
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

Python multi namespace #5375

Merged
merged 77 commits into from
Jan 9, 2025
Merged

Python multi namespace #5375

merged 77 commits into from
Jan 9, 2025

Conversation

msyyc
Copy link
Contributor

@msyyc msyyc commented Dec 16, 2024

For Azure/autorest.python#2795.

Compared to the previous logic that only supported a single namespace, this PR introduces support for multiple namespaces. This primarily requires updates in two key areas:

  1. Serialization approach: We need to account for all namespaces and serialize them individually.
  2. Relative imports: The Python SDK utilizes relative imports internally, and we can no longer make assumptions about the location of models/operations. To determine the correct relative import, we need to know the serialized namespace within the imports function.

Considering these two main changes, here's a detailed summary of the updates in this PR:

  1. Added the emitter flag enable-typespec-namespace, which lets users decide if they want to support native typespec namespace.
  2. Introduced clientNamespace for models/operations/enums/namedUnions/clients: the emitter uses clientNamespace to determine the exact location where the target type should be.
  3. Created get_relative_import_path for CodeModel: all relative import paths should be calculated using this function.
  4. Added a new property client_namespace_types to CodeModel: it counts and stores all namespace types and information about clients/operation_groups/enums/models in each namespace.
  5. Serialization: With the new client_namespace_types property in CodeModel, we can cycle through each namespace and serialize its clients/models/enums/operations using the same logic.
  6. Imports: The old import logic used the relative_path and operation kwargs, which were not set from the top caller but from various functions during the calling process. The signatures were difficult to understand and maintain. I replaces them with the new serialize_namespace and serialize_namespace_type kwargs. Now, any function that needs to calculate relative imports can use these two parameters, which are set from the top caller, making them easier to understand and maintain.

@msyyc msyyc requested a review from tadelesh December 24, 2024 02:00
@msyyc msyyc requested a review from tadelesh December 25, 2024 07:37
Copy link
Member

@tadelesh tadelesh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the changes lgtm. but i really think we should do a refactor to separate the logic of serializing and type status in some time. current logic of import and other serialization thing has too many coupling things. another thing is we should hold merge till we add complicated test cases in spector.

@msyyc msyyc force-pushed the python-multi-namespace branch from 1ca0873 to 0c216f2 Compare January 9, 2025 06:06
@msyyc
Copy link
Contributor Author

msyyc commented Jan 9, 2025

As discussed, we could refactor the implementation after this PR since refactor doesn't influence SDK API. And it will be more safe for refactor if there are already some tests.

@msyyc msyyc added this pull request to the merge queue Jan 9, 2025
Merged via the queue into main with commit 707c1a0 Jan 9, 2025
26 checks passed
@msyyc msyyc deleted the python-multi-namespace branch January 9, 2025 12:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
emitter:client:python Issue for the Python client emitter: @typespec/http-client-python
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants