aliyun-openapi-python-sdk: the V1 Alibaba Cloud SDK kept alive in maintenance mode

The project tells you not to use it, then documents how

The Alibaba Cloud V1.0 Python SDK is in an unusual position for a package that still receives commits. The README opens with an important notice stating that the V1.0 SDK has entered the basic security maintenance phase and is no longer recommended for use, that no new features will be added, and that new projects should go straight to the V2.0 SDK at github.com/aliyun/alibabacloud-python-sdk. It then says, with equal clarity, that if you still need the V1.0 SDK, keep reading.

So the rest of the document is an operating manual for a deprecated product, not a pitch. The repository was last pushed to on 2026-10-09 and is not archived, which is consistent with a codebase that still receives security and compatibility fixes while new development has moved elsewhere.

The scope is enormous in one dimension and simple in another. The repository root holds one directory per Alibaba Cloud product, from aliyun-python-sdk-actiontrail through aliyun-python-sdk-cms and further, and a shared core library, aliyun-python-sdk-core, that all of them sit on. The core is where the real engineering is; the product packages are largely generated surface.

AcsClient plus a versioned request class is the whole calling convention

The call pattern is three steps, and the README states them plainly: create a Client instance, create an API request and set parameters, send the request and handle exceptions.

The mechanism is worth understanding because it explains the shape of nearly every integration you will see. A client is constructed from three values, Region ID, Access Key ID and Access Key Secret, and it carries the signing and transport concern for every call. A request is a class rather than a dictionary, imported from a product package and a dated API version path, so the ECS request classes live in aliyunsdkecs.request.v20140526. The version in that path is the API version the request class targets, which is how the same product can keep an old and a new request shape in one install.

Parameters are set with explicit setters rather than by assignment, and the call is made through a method that raises exceptions instead of returning an error object. Two exception types are imported in the example, ClientException and ServerException, which is the client side and the service side of the same failure, and the fact that they are separate types is what lets a caller distinguish a malformed request from a rejected or failing backend call.

Two pip commands and one credential triple get you to a live API call

Installing the SDK is a matter of two pip commands, the core library and one product package:

pip install aliyun-python-sdk-core # Install the Alibaba Cloud SDK core library
pip install aliyun-python-sdk-ecs  # Install the ECS management SDK

Before that, you need an Alibaba Cloud account and a pair of Access Key ID and Access Key Secret, created and viewed on the AccessKey management page in the console or supplied by your system administrator, and the relevant product has to be activated in the console before its API will answer. Region ID comes from the region list linked in the README.

The first working call looks like this, using the ECS product as the example:

from aliyunsdkcore.client import AcsClient
from aliyunsdkcore.acs_exception.exceptions import ClientException
from aliyunsdkcore.acs_exception.exceptions import ServerException
from aliyunsdkecs.request.v20140526 import DescribeInstancesRequest

client = AcsClient(
   "<your-access-key-id>",
   "<your-access-key-secret>",
   "<your-region-id>"
)

request = DescribeInstancesRequest.DescribeInstancesRequest()
request.set_PageSize(10)

response = client.do_action_with_exception(request)
print response

Two things to notice. The parameter is set with set_PageSize(10), a method call on the request object. And the README's own listing still ends with a Python 2 style print statement, while the same document states that from version 2.16.0 of aliyun-python-sdk-core the library supports Python 3.7 and above. The sample is stale in that one line, and it is a small reminder that the documentation for the V1 line is no longer being refreshed with the same care.

The DEBUG environment variable exposes the raw signed request

One diagnostic feature is documented in detail. Setting the DEBUG environment variable to either sdk or SDK turns on HTTP debug output, and the README shows what that looks like: the outgoing request line, the Host, User-Agent, Accept and Connection headers, and the Alibaba Cloud specific headers x-acs-version, x-acs-region-id, x-acs-signature-method, x-acs-signature-version and an Authorization header. The response side is shown too, with the status line, the x-acs-request-id and the Server header.

This is the single most useful debugging tool in the package because it exposes what the SDK actually put on the wire. A signature failure, a wrong region, a mismatched product version and a proxy that rewrites headers all become visible in a form you can read, and the x-acs-request-id value in the response is the identifier you quote when you take the problem to the vendor.

The tradeoff is that the same output contains an Authorization header and an access key context. The README shows the value truncated, but the header is present in the debug stream, so this switch belongs in a development environment and not in a production process that writes its environment anywhere shared. The switch itself is a single environment variable named `DEBUG`, whose value the README gives as either `sdk` or `SDK`, so it is enabled before the process starts rather than through any client argument.

For diagnostics that need no code change, the README also points to a troubleshooting page at api.aliyun.com that accepts a RequestID or an error message and returns suggested solutions.

The topic documentation lives in a folder of Chinese-language files

The documentation list in the README is a set of files in the docs directory, each covering one narrow concern: environment requirements, installation, client and credentials, timeout mechanism, proxy configuration, logging, endpoints, HTTPS configuration, debugging, and exceptions. Every one of those names ends in -CN.md, so the shipped topic documentation is Chinese.

The coverage is a strength for a project of this age and size, because these are exactly the areas where a generated SDK hides surprises. Timeouts, proxies, endpoint selection and HTTPS settings are where an integration quietly fails, and having a dedicated note on each means a developer can check a behaviour instead of reverse engineering it.

The limitation is that a non-Chinese-reading team has to translate, and the README itself has no English counterpart to the docs folder, although it does have a separate README_zh.md, which means the Chinese README is the parallel file rather than an afterthought. There is also no single narrative guide to the request class pattern, so the model of how products map to request classes has to be learned from the directory layout and the code.

Migrating to V2.0 is the vendor's own advice, but its own README says the least about it

The alternative to staying on V1.0 is the V2.0 SDK, and the difference in approach as described here comes from the V1.0 README itself. Its claim is that V2.0 provides better performance, a more concise API, and more complete documentation, and that new projects should use it directly while existing V1.0 projects are advised to migrate as soon as possible.

That is the whole of what is stated. The README links to the V2.0 repository and to a developer reference page for the V2 Python integrated SDK, and to a developer portal that can invoke cloud product OpenAPIs online, generate SDK example code and search for APIs. But it does not describe the V2.0 calling convention, so a team cannot scope a migration from this document alone. Anyone asked to move will need to read the V2.0 reference and compare it against the shape their own code uses, which is the request class per API version and the AcsClient wrapper.

The portal is the more immediately useful piece for either line. Being able to invoke an API online and generate example code for a specific call is a fast way to find the current request shape for a product, and it is the fastest way to test whether the V1.0 request class you are about to rely on still behaves as you expect.

A permissive licence, a Makefile with a v3 target, and no published releases

The README points to Apache-2.0 and the repository carries a License file at its root, though GitHub's own classification for the repository is Other, meaning it could not map the file to a standard licence identifier and the text is worth reading directly before you rely on it for compliance. Apache-2.0 in practice places no obligation on commercial use and requires that notices be preserved, and the wording in the file is what governs.

The Makefile shows how the core library is exercised. There is a lint target running pycodestyle with an explicit ignore list and a max line length of 120 over the core directory, a test target that runs coverage with branch coverage over aliyunsdkcore with pytest, a functional-test target that runs./run_all_test.sh, a coverage-report target that omits the vendored directory, compat.py and the data directory, and a release-core target that calls release-core.sh six times. That last target runs a core and a core-v3 pass, so a v3 core build path is scripted in this V1.0 repository even though the public story is V1.0 to V2.0.

On release hygiene, the repository has no GitHub releases. A CHANGELOG.md exists at the root, and the version line most recently mentioned in the README is 2.16.0 for the Python 3.7 support change. So version history lives in the changelog file and on the package index rather than in tagged releases, which is a small but real inconvenience when you want to know what changed between two pinned versions.

Editorial conclusion

Choose the V1 SDK only for an existing service whose migration to the V2.0 SDK is larger than the risk of staying, and treat it as a dependency you plan to remove, not one to build on. The README states that the V1.0 SDK is in basic security maintenance with no new features, so the first thing to verify is whether your deployment still pulls aliyun-python-sdk-core, and if it does, whether migrating to the V2.0 SDK is a package import change or a rewrite of every request object, because the V1 call shape, AcsClient plus a versioned request class, is the part that carries the most code.

Frequently asked questions

Official sources

1. aliyun/aliyun-openapi-python-sdk on GitHub
2. Issues
3. README