-
Notifications
You must be signed in to change notification settings - Fork 39
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
V3: shrink package size #3422
Comments
Size in megabytes isn't the most concerning problem for this provider IMO – rather the number of symbols/objects the IDE's language server has to analyze & index, for properly typed experience. As mentioned in #3124 the sheer number of objects in this provider, due to the breadth of the Azure API and autogenerated nature of this provider, causes the Python Language Server to run out of memory and blow up. Now with the introduction of #3400 number of symbols in the provider seems to have increased by roughly 30k: $ grep -Ri 'ArgsDict(TypedDict)' . | wc -l
29958 I really like the direction of TypedDicts and assume they will supersede the Args classes in the next major version but this seems to have made matters even worse than before, causing more frequent crashes of the Python Language Server in VScode. |
Is LSP performance improved or affected by how pulumi_azure_native is imported? # import named types:
from pulumi_azure_native.storage import ...
# import submodule
from pulumi_azure import storage
# import package
import pulumi_azure |
Don't know if this is getting out of scope but I guess these are in the end symptoms caused by the size/breadth of the SDK – @thomas11 feel free to comment if you want Python/IDE/typing specific issues/symptoms to be tracked in a sub/seperate issue.
For sure, I took another shot at investigating the behaviour in a freshly created azure-native Python project and even when being extra careful with your imports something like hovering over a module and navigating to its definition will kick off a library-wide scan. After some unstructured browsing through issues of similar nature tracked in Pyright & MyPy affecting other large Python libraries I wanted to throw some ideas into the mix that might (?) improve IDE experience in generated Python SDKs:
|
@olafurnielsen appreciate the insight and citations here. I think I can speak for Pulumi and say great feedback like this really helps us hone our product. |
Added to epic https://github.com/pulumi/home/issues/3552 |
I would like to add that this problem is not unique to |
A perhaps obvious solution would be to produce a separate library for each Azure API, all tied to the "azure-native" plugin. This would force the user to have more fine-grained dependencies, with benefits felt across all languages. A wilder idea is to make it easy to generate a project-specific SDK that is tailored to have specific Azure APIs. Imagine some sort of parameterized provider with a configuration block in Pulumi.yaml to select your preferred api versions on a per-API basis. |
This is an interesting approach: https://github.com/Ankvi/pulumi-azure-native. It splits out every sub-namespace into its own NPM package. Apparently, this is working well for them in practice ("night and day difference, perf-wise.") They said the usability hit of needing to add additional package references isn't bad and there is precident in other projects, like Angular. |
…3899) Part of #3422. Determine API versions that are older than any _previous_ default version in a module. These are good candidates for removal. --------- Co-authored-by: Daniel Bradley <[email protected]>
This is an open-ended issue to capture ideas and investigations on how we could shrink the size the provider and its SDK. The v3 major version bump might provide opportunities for breaking changes.
The text was updated successfully, but these errors were encountered: