Proposal to delete the services/ directory

[heaths]

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 and azure_identity, I would like to avoid the distractions of having to keep the old generated crates up to date:

1. Tag the sources now for easy reference later.
2. 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 or resourcemanager.

[demoray]

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.

[demoray]

In particular, I use the following:

• azure_mgmt_batch
• azure_mgmt_compute
• azure_mgmt_resourcegraph
• azure_mgmt_storage
• azure_svc_applicationinsights
• azure_svc_batch
• azure_svc_eventgrid
• azure_svc_graphrbac

[heaths]

To compare with how we do this in other Azure SDK languages:

• .NET: Azure.ResourceManager.{service} under sdk/{service} as Azure.ResourceManager.{service} next to data-plane (DP) packages.
• Go: github.com/Azure/azure-sdk-for-go/sdk/resourcemanager/{service}/arm{service} under sdk/resourcemanager.
• Java: com.azure.resourcemanager.{service} under sdk/resourcemanager as azure_resourcemanager_{service} directories.
• Python: azure-mgmt-{service} under sdk/{service}/azure-mgmt-{service} next to DP packages.
• TypeScript/JavaScript: @azure/arm-{service} under sdk/{service} as arm-{service} next to DP packages.

Perhaps we keep "mgmt" for control-plane (CP) packages but we should eliminate "svc" for DP packages.

[RickWinter]

Going with ResourceManager aligns with Azure documentation https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/overview Our documentation describes ResourceManager as the way to deploy and manage resources in Azure.

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 sdk/resourcemanager and then name packages azure-resourcemanager-<svc>. Python seems to be the oddity using mgmt

[heaths]

@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.

[cataggar]

Because we expect to do some refactoring - hopefully nothing major - in azure_core and azure_identity, I would like to avoid the distractions of having to keep the old generated crates up to date

The generated crates do not depend on azure_identity, only azure_core. I don't understand why they would need to be nuked to do refactoring of azure_core. May be disable CI for them on your PR?

Python seems to be the oddity using mgmt

Right, mgmt was taken from Python. Short crate names were preferred.

[heaths]

No crates should depend on azure_identity, only azure_core::TokenCredential. That's true of all our languages.

Most, if not all, resource management libraries will be moved under sdk/. We do this in all other languages. It shouldn't matter that they are generated or not. Most of our languages are strictly generated, and this investment is increasing. What benefit is there putting them in a different root directory?

Thanks for the info on mgmt for brevity. To be honest, I don't see a lot of brevity in many crates I use, but I'm not opposed to it. At the same time, Go also is keyboard-averse but still has "resourcemanager" in their fully qualified package names e.g., github.com/Azure/azure-sdk-for-go/tree/main/sdk/resourcemanager/keyvault/armkeyvault. Granted, in this case, the import allows you to refer only to armkeyvault.NewSecretsClient().

[heaths]

Existing crates will be community-maintained in a legacy branch created from main before we move feature/track2 to main.