# Azure SDK for Python: a monorepo of per-service libraries, not one big package > The Azure SDK for Python ships as dozens of separately installable client and management libraries under a single repository. This is what the layout, install model and telemetry opt-out actually mean for a team deciding whether to depend on it. **Azure/azure-sdk-for-python** — This repository is for active development of the Azure SDK for Python. For consumers of the SDK we recommend visiting our public developer docs at https://learn.microsoft.com/python/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-python. - Repository: https://github.com/Azure/azure-sdk-for-python - Stars: 5,609 · Forks: 3,373 - Language: Python - License: MIT - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/azure-azure-sdk-for-python ## The problem: Azure is not one API, and one package would be the wrong shape Azure is a collection of services with independent release cycles. The README reflects this directly: each service has a separate set of libraries you can choose instead of one large Azure package, and service libraries live in the /sdk directory. That is the whole design premise. If you only need to upload a blob, you install the storage client and you do not carry compute, key vault and management code with it. The audience is Python developers who consume existing Azure resources (upload a blob, read a secret) and, separately, developers who provision and manage resources. The README splits these into client libraries and management libraries, the latter identifiable by namespaces starting with azure-mgmt-, such as azure-mgmt-compute. Those two groups are not interchangeable, and the README treats them as distinct categories with distinct documentation links. ## How the repository is actually organized: /sdk, azure-core, and four package categories The README names four categories: Client New Releases, Client Previous Versions, Management New Releases, and Management Previous Versions. New client releases are announced as GA, with several still in preview. The distinction matters because the README states plainly that if you need your code ready for production, you should use a stable, non-preview library. What ties the new-generation packages together is azure-core, which the README describes as the shared home for retries, logging, transport protocols and authentication protocols. Management libraries in the new set additionally get the Azure Identity library, an HTTP pipeline with custom policies, error handling and distributed tracing. Older libraries may not implement the SDK design guidelines or match the newer feature set, though the README notes they offer wider coverage of services. That is a real trade-off, not a marketing line: broader service coverage on one side, guideline conformance and shared core behavior on the other. The repository root confirms the structure rather than contradicting it. setup.py walks glob patterns for azure*/setup.py and sdk/*/azure*/setup.py to build a package map, and it explicitly excludes meta-packages named azure-keyvault, azure-mgmt, azure and azure-storage from the content package list. azure-common is moved to the front of the install order. That code is the clearest available evidence that this repo is a packaging harness for many distributions, not a single library. ## Installing one library instead of the whole SDK The README does not give a single top-level pip command for the SDK. It says to get started with a specific library, read the README.md or README.rst in that library's project folder, which you find under /sdk. So the install step is per package. A typical client library install looks like this: ```bash pip install azure-storage-blob ``` After that, the README's telemetry section gives a concrete client-construction example using azure-storage-blob, which is the closest thing in the repository to a first real use. It imports ManagedIdentityCredential from azure.identity, BlobServiceClient from azure.storage.blob, and UserAgentPolicy from azure.core.pipeline.policies. ```python import os from azure.identity import ManagedIdentityCredential from azure.storage.blob import BlobServiceClient from azure.core.pipeline.policies import UserAgentPolicy ``` What you should see is a client created with an explicit credential object rather than a connection string, and the same pattern repeated for every service client you build. The README is explicit that you do this for every new client. ## Telemetry is on by default, and the opt-out is per client The README states that the software may collect information about you and your use of the software and send it to Microsoft, and that telemetry collection is on by default. The documented opt-out is not an environment variable or a global switch. You define a NoUserAgentPolicy class that subclasses UserAgentPolicy with an on_request method that does nothing, then pass an instance as the user_agent_policy keyword argument when creating a client. The README says this disables telemetry for all methods in that client, and that you must do it for every new client. That is a design cost worth naming. If your codebase constructs clients in a dozen places, the opt-out has to be threaded through each construction site, and a single missed client silently keeps telemetry on. There is no repository-level configuration shown in the README that would centralize it. Teams with strict data-egress rules should treat this as something to verify in their own code before rollout, not something the SDK handles for them. ## Where it stops being the right tool If you want one import that covers all of Azure, this is the wrong shape. The README's own framing is that you choose per-service libraries instead of one large package, and the root setup.py excludes the azure meta-package from what it installs as content. Reaching for a single package gets you a different, older surface than the guideline-conformant libraries. Preview status is the second trap. The README warns twice, once for client and once for management, that production code should use stable non-preview libraries. The recent release list shows this is not hypothetical: azure-template-two_1.0.0b1 and azure-mgmt-containerserviceaimanager_1.0.0b2 are beta-tagged, while azure-mgmt-resource-policy_1.0.0 is not. A dependency that resolves to a b-suffixed version is a dependency that can change behavior between minor releases. The third case is authentication drift on upgrade. The README notes that if you hit authentication issues with the management libraries after upgrading, it is possible you upgraded to new SDK versions without changing the authentication code, and points to the migration guide in doc/sphinx/mgmt_quickstart.rst. Upgrading the package alone is not a complete upgrade. ## What it is not: the Java SDK, and what the Python version policy covers People searching for the Azure SDK for Java are looking at a different repository with its own release cadence and its own design guidelines. Nothing in this repository transfers between the two beyond the shared Azure SDK conventions. If you are choosing a language for an Azure integration, the Python repository tells you nothing about the Java one. On Python versions, the README says the client libraries support multiple versions of Python and defers the specifics to the version support policy document at doc/python_version_support_policy.md. That document is not reproduced in the README, so the exact supported range is something to read at the source rather than assume. The same applies to Python 3.13 in Azure Functions, which is a Functions runtime question, not something this repository's README answers. ## Maintenance, licensing and the cost of upgrading The repository is not archived, and the last push was on 2026-09-22, with releases the same week including azure-template-two_1.0.0b1 on 2026-09-22 and azure-mgmt-resource-policy_1.0.0 on 2026-09-21. That is a fast release cadence, and it is the main upgrade cost: you are tracking many independent packages, each with its own version, rather than one dependency whose changelog you read once. The licence is MIT, stated in the repository metadata, with a NOTICE.txt file at the root. MIT is permissive and does not impose copyleft obligations on your own code, but the NOTICE file and the data-collection terms are separate documents from the licence, and the README's telemetry section describes data being sent to Microsoft. If your organization reviews vendor data flows, that section is the one to read, not the licence header. Nothing here is legal advice; read LICENSE and NOTICE.txt yourself. ## Conclusion Adopt it if you are building against Azure services in Python and want per-service packages with a shared core for retries, logging and authentication; pick stable non-preview releases for production code. Do not treat the repository root as an installable SDK, and do not expect the README to walk you through a first call: it points you at each library folder and the versioned developer docs instead. Before you commit, verify three things: that the specific package you need is GA rather than preview, that its README in /sdk documents the auth path for your environment, and whether you need the telemetry opt-out, which the README says must be passed as user_agent_policy=NoUserAgentPolicy() on every client you construct. ## FAQ ### Can I use the Azure SDK for Python? Yes. The repository is the active development home of the Azure SDK for Python, and the README directs consumers to the public developer docs and the versioned developer docs for usage. Client libraries support multiple versions of Python, with details in the version support policy document. ### Can you use Python with Azure? The repository exists specifically to let Python code consume and manage Azure resources. Client libraries let you use and consume existing resources, for example uploading a blob, while management libraries, identifiable by azure-mgmt- namespaces, provision and manage resources. ### What is a Python SDK? In this repository the term covers a set of separately installable libraries rather than one package. The README says each service has its own libraries, found in the /sdk directory, and that new-generation packages share core functionality such as retries, logging, transport and authentication protocols through azure-core. ### How do I install the Azure SDK for Python? There is no single top-level install command in the README. It says to get started with a specific library by reading the README.md or README.rst in that library's project folder under /sdk, and the package is then installed from PyPI by name, for example azure-storage-blob. ### What is the Azure SDK for Python? It is the repository for active development of the Azure SDK for Python, containing client libraries that consume existing resources and management libraries that provision and manage them. New client releases are announced as GA alongside preview packages, and the README advises using stable non-preview libraries for production. ### Is the Azure SDK for Python from Microsoft? Yes. The README describes the repository as the active development home of the Azure SDK for Python, the copyright header in setup.py credits Microsoft Corporation, and the telemetry section says collected data is sent to Microsoft. ## Sources - [Azure/azure-sdk-for-python on GitHub](https://github.com/Azure/azure-sdk-for-python) - [Issues](https://github.com/Azure/azure-sdk-for-python/issues) - [License: MIT](https://github.com/Azure/azure-sdk-for-python/blob/main/LICENSE) - [README](https://github.com/Azure/azure-sdk-for-python/blob/main/README.md) - [Releases](https://github.com/Azure/azure-sdk-for-python/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/azure-azure-sdk-for-python