-
Notifications
You must be signed in to change notification settings - Fork 226
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
Proposal to delete the services/ directory #1607
Comments
Is there a path forward for users of the existing crates to request the inclusion of the maintained crates moving forward? In particular, there are a handful of generated crates that I make use of that I would prefer to keep managing moving forward. |
In particular, I use the following:
|
To compare with how we do this in other Azure SDK languages:
Perhaps we keep "mgmt" for control-plane (CP) packages but we should eliminate "svc" for DP packages. |
Going with ResourceManager aligns with Azure documentation Azure Resource Manager is the deployment and management service for Azure. It provides a management layer that enables you to create, update, and delete resources in your Azure account. You use management features, like access control, locks, and tags, to secure and organize your resources after deployment. To stay in alignment with the other languages, we place the code at |
@bterlson I'm going to update our guidelines to match, but I noticed TypeSpec's guidelines are also not congruent with practice. Want me to fix those as well? In fact, seems you copied the general guidelines, which isn't necessary and create duplicative work to maintain. You might consider just deleting that table entirely and fall back to general guidelines. |
The generated crates do not depend on
Right, |
No crates should depend on Most, if not all, resource management libraries will be moved under Thanks for the info on |
While our goal is to generate most of the SDKs and add value where oft-used and helpful e.g., batch operations, we do not separate generated (DPG, formerly LLC) and hand-written (HLC) libraries in other languages. The crates - by design - also do not have the naming convention we want to use, according to our guidelines on namespace/package names. We knew this going in, which is why they took on a different name. Still, the overall structure of the generated clients and models we're likely to retain for the most part (Rust-specific guidelines are still being finalized and written).
Because we expect to do some refactoring - hopefully nothing major - in
azure_core
andazure_identity
, I would like to avoid the distractions of having to keep the old generated crates up to date:gm rm -r services/
to nuke the generated crates.Optionally, we could publish them one last time with a
README.md
that notes they are deprecated; however, it might make more sense to have some replacements for oft-used ones including, from anonymized telemetry:azure_mgmt_compute
azure_mgmt_network
azure_mgmt_dns
azure_mgmt_resourcegraph
Still, these are not names we are likely to keep. In most languages, these would use either
management
orresourcemanager
.The text was updated successfully, but these errors were encountered: