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

simplify use of default_tag #1506

Merged
merged 1 commit into from
Dec 8, 2023
Merged

Conversation

demoray
Copy link
Contributor

@demoray demoray commented Dec 8, 2023

Most of the time, tag is analogous to "API version", but not always. The idea is to allow the following:

  • Allow the generated crate user to specify which tags they want if they want something specific
  • Allow the SDK developer to rely on the "usual" behavior where it's API version, and use the "latest" without having to continuously update the SDK crate based on a steady churn of the generated crates
  • When user uses both the generated crate and the SDK-crate, it doesn't violate either of the above ideals
  • Allow users to use both generated crates and the SDK-crate without multiple imports of the same crate as the generated crates can be huge. (For reference, azure_svc_blobstorage is ~5M of source, and each feature is ~1M)

This change modifies the generated import behavior thusly:

  • Any tag that is selected by feature name is available for use via use crate_name::tag_name::models;
  • If the default_tag feature is selected, then the tag is included by feature name and can be used via use crate_name::tag_name::models;
  • If the default_tag feature is selected, then the implementation for that specific tag is imported at the top level for the crate, such that it can also be used as use crate_name::models;
  • Import behavior no longer changes based on features specified, which was a "footgun" that users hit because rust Crate feature flags are additive

Most of the time, tag is analogous to "API version", but not always.  The idea is to allow the following:

* Allow the generated crate user to specify which tags they want if they want something specific
* Allow the SDK developer to rely on the "usual" behavior where it's API version, and use the "latest" without having to continuously update the SDK crate based on a steady churn of the generated crates
* When user uses both the generated crate and the SDK-crate, it doesn't violate either of the above ideals
* Allow users to use both generated crates and the SDK-crate _without_ multiple imports of the same crate as the generated crates can be huge.  (For reference, azure_svc_blobstorage is ~5M of source, and each feature is ~1M)

This change modifies the generated import behavior thusly:
* Any tag that is selected by feature name is available for use via `use crate_name::tag_name::models;`
* If the `default_tag` feature is selected, then the tag is included by feature name (and can be used via `use crate_name::tag_name::models;`
* If the `default_tag` feature is selected, then the implementation for that specific tag is imported at the top level for the crate, such that it can _also_ be used as `use crate_name::models;`
@demoray demoray merged commit 6d03297 into Azure:main Dec 8, 2023
19 checks passed
@demoray demoray deleted the change-default-tag-behavior branch December 8, 2023 19:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants