You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Generate code cause too-many-locals and Unused import urllib.parse
2
-
3
-
## question
4
-
Hello Language - Python Got issue with code gen... When I run lint using next-pylint
5
-
```
6
-
tox run -e next-pylint -c ../../../eng/tox/tox.ini --root .
7
-
```
8
-
I am getting
9
-
azure/ai/agents/aio/operations/_operations.py:1357: [R0914(too-many-locals), RunsOperations.create] Too many local variables (34/25)
10
-
azure/ai/agents/aio/operations/_operations.py:4090: [R0914(too-many-locals), AgentsClientOperationsMixin.create_agent] Too many local variables (26/25)
11
-
azure/ai/agents/aio/operations/_operations.py:4475: [R0914(too-many-locals), AgentsClientOperationsMixin.update_agent] Too many local variables (27/25)
12
-
azure/ai/agents/aio/operations/_operations.py:4815: [R0914(too-many-locals), AgentsClientOperationsMixin.create_thread_and_run] Too many local variables (32/25)
The _operations.py is straightly created by code gen. Need advise how to fix them..
16
-
17
-
## answer
18
-
The issues you're seeing when running `next-pylint` are due to `_operations.py` being a generated file, and `next-pylint` referencing a different `pylintrc` file.
19
-
20
-
We already have some exclusion of emitted files in the root `pylintrc`, like:
So I would not expect the errors you show to be in the CI pipeline, only when you run locally.
27
-
28
-
The problem is that `next-pylint` uses `eng/pylintrc`, and this file doesn’t include the same ignore-paths for agents. That’s an oversight on my part.
29
-
30
-
We have a separate `pylintrc` file for `next-*` as we have to ignore the next- pylint checks added every 3 months to not break everyday CI while still allowing users to fix the next-* warnings.
31
-
32
-
We will update the `eng/pylintrc` to align with the ignore-paths added to the root `pylintrc`. You can refer to this PR for the fix:
This should address the `too-many-locals` and `unused import urllib.parse` warnings you’re seeing.
37
-
38
1
# Release pipeline failing
39
2
40
3
## question
41
4
Hi Language - Python,
42
5
Wondering why this pipeline is failing: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=4959365&view=logs&j=447d33cb-e696-5bdf-6dab-daffaacae469
ImportError while importing test module '/mnt/vss/_work/1/s/sdk/healthinsights/azure-healthinsights-cancerprofiling/tests/test_cancer_profiling.py'.
10
+
Hint: make sure your test modules/packages have valid Python names.
11
+
Traceback:
12
+
.tox/mindependency/lib/python3.13/site-packages/azure/core/rest/__init__.py:27: in <module>
13
+
from ._rest_py3 import (
14
+
.tox/mindependency/lib/python3.13/site-packages/azure/core/rest/_rest_py3.py:40: in <module>
15
+
from ._helpers import (
16
+
.tox/mindependency/lib/python3.13/site-packages/azure/core/rest/_helpers.py:28: in <module>
17
+
import cgi
18
+
E ModuleNotFoundError: No module named 'cgi'
19
+
```
44
20
45
21
## answer
46
-
Your nightly/internal pipeline is failing due to a Python 3.13 error that’s been happening for the past couple months. The root cause is that `azure-healthinsights-cancerprofiling` specifies too old of a minimum version of `azure-core` for Python 3.13, where `cgi` was removed.
47
-
48
-
Your PR checks passed because you only changed `azure-healthinsights-radiologyinsights`, and the pull request build is scoped to only that package. However, internal builds are service-wide, so they include all packages in the `healthinsights` folder, even those not being released. That's why the failure surfaced internally.
49
-
50
-
To unblock you, I ran a build that artificially limits the build scope to only `azure-healthinsights-radiologyinsights`, which should allow you to release successfully.
22
+
Your PR checks passed because you only changed `azure-healthinsights-radiologyinsights`, and the `pull request` build is scoped to only that package. However, `internal` builds are service-wide, so they include all packages in the `healthinsights` folder, even those do not have a release stage. That's why the failure is only on the `internal` build.
51
23
52
-
If `azure-healthinsights-cancerprofiling` is deprecated and not going to be released again, we should follow the deprecation process as outlined here:
If we might need to release it again someday, we should fix the dependencies to keep it from falling into bitrot.
24
+
To unblock you, please run a build that artificially limits the build scope to only `azure-healthinsights-radiologyinsights` by adding variable `BuildTargetingString` with value `azure-healthinsights-radiologyinsights`.
Hi, we already commit some basic tests for the PR and we pass those test locally. For mgmt SDK, it shall be enough. Of course, it would be nice if you are willing to commit more tests by yourselves. You can refer the guidance [azure-sdk-for-python/doc/dev/tests.md at main · Azure/azure-sdk-for-python](https://github.com/Azure/azure-sdk-for-python/blob/main/doc/dev/tests.md) and our last commit for test [[AutoRelease\] t2-oracledatabase-2025-06-05-34855(can only be merged by SDK owner) by azure-sdk · Pull Request #41428 · Azure/azure-sdk-for-python](https://github.com/Azure/azure-sdk-for-python/pull/41428/commits/fbcfd9783d2933d5c3258cdb3a30d032b20170cd).
65
-
66
-
# Code generator on python validates versions by comparing literals.
67
-
68
-
## question
69
-
Hello, Language - Python!
70
-
We have an SDK code with three different versions:
We have added the method in version v1 and the swagger has generated correctly: this method was present in both v1 and 2025_05_15_preview ([Add thread message delete operation by nick863 · Pull Request #35320 · Azure/azure-rest-api-specs](https://github.com/Azure/azure-rest-api-specs/pull/35320/files)). When I have generated the Python code, the validation code directly [compares literals](https://github.com/Azure/azure-sdk-for-python/blob/68f3822229eba94c3fb49a29b57b8f37c85845cf/sdk/ai/azure-ai-agents/azure/ai/agents/_validation.py#L24), which leads to the fact that 2025_05_15_preview seems to be not supported anymore as "v1" is technically greater then "2025_05_15_preview". Is there a possibility to compare enum values as opposed to literals?
75
-
76
-
## answer
77
-
The issue you're encountering is because the validation code directly compares literals, so 2025_05_15_preview seems to be not supported anymore as v1 is technically greater than 2025_05_15_preview.
78
-
79
-
But this validation code was not designed to work when API version scheme is not consistent from a version to another, and TypeSpec semantic for version ordering is not lexical, it's the order in the file. So codegen needs to follow TypeSpec semantic since this is our source of truth.
80
-
81
-
We confirmed this is wrong and decided to fix it. As a solution:
82
-
83
-
I have PRs out both for disabling the versioning validation, and for validating API versioning by checking the spec ordering.
84
-
85
-
The emitter has been released, I'm just currently in the process of updating the emitter-package.json in the azure-sdk-for-python repo.
Copy file name to clipboardExpand all lines: QA/python-0703.md
+11-15Lines changed: 11 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,7 +37,7 @@ The recommended approach is to create a custom error format class like:
37
37
class BatchErrorFormat(ODataV4Format):
38
38
# Custom parsing logic here
39
39
```
40
-
Then, wrap the operation call like this:
40
+
Then, wrap the operation calls like this:
41
41
```
42
42
try:
43
43
generated_client.op()
@@ -56,26 +56,22 @@ class BatchExceptionPolicy:
56
56
except HttpResponseError as err:
57
57
raise HttpResponseError(response=err.response, model=err.model, error_format=BatchErrorFormat) from err
58
58
```
59
-
This policy can be injected once into the client constructor using per_call_policies, making it a scalable and maintainable solution. No new feature is needed for this—it’s supported today.
59
+
Then inject the policy into the client constructor using `per_call_policies`: https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/core/azure-core/CLIENT_LIBRARY_DEVELOPER.md#pipeline
60
60
61
61
# pipeline got stuck
62
62
63
63
## question
64
64
Hello,
65
-
I have a feature branch that won't be merged to main. I just want to release it. Before I do that, I want to make sure the pipeline is green. But it is stuck currently. Could someone help?
65
+
I have a feature branch that won't be merged to main. I just want to release it. Before I do that, I want to make sure the pipeline is green. But it is stuck currently. Could someone help?
66
66
[Feature/azure ai agents/1.0.2 by howieleung · Pull Request #41623 · Azure/azure-sdk-for-python](https://github.com/Azure/azure-sdk-for-python/pull/41623)
67
67
68
68
## answer
69
-
If your pipeline is stuck and you're working from a feature branch that won't be merged to main, but you still want to release it, here's what you can do:
69
+
You can simply run your internal release build against the release branch. If it reaches the "approve release" phase, you're good to go, it's actually more certain than if you got a PR build to run.
70
70
71
-
First, although your PR has conflicts, you mentioned that rebasing isn't appropriate because the main branch contains the latest beta code, while your feature branch is for a stable release. In this case, you can simply run your internal release build against the release branch. If it reaches the "approve release" phase, you're good to go.
72
-
73
-
You don’t have to approve a manually queued internal build, and this is consistent with how you've handled prior stable releases. Running the pipeline as a final check is understandable, even if not strictly required.
74
-
75
-
If you're trying to maintain the PR build pattern, here's a recommended approach:
76
-
77
-
Get your release branch to the desired state, excluding changelog and version updates.
78
-
Submit a PR targeting your release branch that includes the changelog and version updates.
79
-
The PR build will use the merge commit from both branches in the python - pullrequest pipeline, avoiding conflicts with main.
80
-
Once merged, your release branch will be in its final state, and you can queue the release build.
81
-
To clarify, the release build runs all the same tests plus a few more. If your goal is to validate the final public PR, this method works well with release branches.
71
+
Yet if you want to maintain the PR build pattern. I do have a recommendation how you can make that work with release branches.
72
+
73
+
1. Get your release branch where you want it to be minus `changelog` and `version` updates.
74
+
2. Submit a PR targeting your release branch with the `changelog` and `version` updates. the PR build will use the merge commit from both your branches in the `python - pullrequest` pipeline, instead of hitting conflicts with `main`.
75
+
3. Merge that. Your release branch will be in final state, which you can queue the release build for.
76
+
77
+
To be clear, your release build will run all the same tests + a couple more, but if it's really about the last public PR then that's how you would do it with a release branch
Copy file name to clipboardExpand all lines: QA/python-0717.md
+4-20Lines changed: 4 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,33 +1,17 @@
1
-
# API View Displays Incorrect Python Package Name
2
-
3
-
## question
4
-
Hi team,
5
-
6
-
I am generating the Python SDK api view for sdk review meeting. After I followed the instruction here to generate Python package: [What to do after generating the SDK code with codegen · Azure/azure-sdk-for-python Wiki](https://github.com/Azure/azure-sdk-for-python/wiki/What-to-do-after-generating-the-SDK-code-with-codegen#how-to-create-package). It generate a package name like this: **azure_ai_language_text-1.0.0b1-py3-none-any.whl**, with long suffix. And after uploading it to Api view, it still keep the same long name:
7
-
`azure_ai_language_text-1.0.0b1-py3-none-any.whl`
8
-
But I noticed that in the previous version api view, the Python namespace only show simplified verison like this :
9
-
`azure-ai-language-conversations`
10
-
Should I manually modify the package name before uploading it to api view, or is there anything that I was missing? Thank you!
11
-
12
-
## answer
13
-
Hi, this is a bug in the parser and an issue is filed for it here. [[Python APIView\] manual uploads have the whl as the title name · Issue #10459 · Azure/azure-sdk-tools](https://github.com/Azure/azure-sdk-tools/issues/10459)
14
-
15
-
I'm currently working on fixing this. Is there a particular reason for the manual upload? Otherwise, you can auto-generate the APIView with the correct name by opening up a PR in the azure-sdk-for-python repo with the changes.
16
-
17
1
# Python Live Test for async api
18
2
19
3
## question
20
4
Hello Language - Python,
21
-
5
+
22
6
We at Callautomation are working on adding live tests for the async APIs. When I tried to run a live test, I encountered an SSL certificate issue, as shown below. Could you help me understand what I might be missing?
23
-
7
+
24
8
```
25
9
except aiohttp.client_exceptions.ClientError as err:
26
10
> raise ServiceRequestError(err, error=err) from err
27
11
E azure.core.exceptions.ServiceRequestError: Cannot connect to host localhost:5001 ssl:True [SSLCertVerificationError: (1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate (_ssl.c:1028)')]
You're encountering an SSL certificate error when running live tests for async APIs, specifically when connecting to https://localhost:5001. This is the test proxy endpoint, and the error is likely due to certificate verification failing. Although the same code works for another team member, the issue may be caused by environment variables — either missing or incorrectly set.
Copy file name to clipboardExpand all lines: QA/python-0724.md
+2-5Lines changed: 2 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -85,10 +85,10 @@ But the issue still persists. Has anyone encountered this before or could share
85
85
## answer
86
86
Maybe you could try install "uv" (here is guidance [Installation | uv](https://docs.astral.sh/uv/getting-started/installation/)) and sync with latest main branch of python sdk repo then try again.
87
87
88
-
# "The date for the changelog being released must be the latest in the file."
88
+
# The date for the changelog being released must be the latest in the file.
89
89
90
90
## question
91
-
We have this PR to Main branch that updates CHANGELOG.md: https://github.com/Azure/azure-sdk-for-python/pull/42064 . The change looks correct to me... adding `## 1.0.0b13 (Unreleased)`. Yet the PR build pipeline has an error in the Analyze job titled "Verify ChangeLogEntries":https://dev.azure.com/azure-sdk/public/_build/results?buildId=5108808&view=logs&j=b70e5e73-bbb6-5567-0939-8415943fadb9&t=ac8f4042-9b76-5db4-27b1-2a4abaa9bb3c :
91
+
We have this PR to Main branch that updates CHANGELOG.md: https://github.com/Azure/azure-sdk-for-python/pull/42064 . The change looks correct to me... adding `## 1.0.0b13 (Unreleased)`. Yet the PR build pipeline has an error in the Analyze job titled "Verify ChangeLogEntries":
92
92
```
93
93
[debug]Verifying as a release build because the changelog entry has a valid date.
94
94
##[error]Invalid date [ 2025-06-23 ]. The date for the changelog being released must be the latest in the file.
@@ -104,10 +104,7 @@ We have this PR to Main branch that updates CHANGELOG.md: https://github.com/Azu
104
104
Finishing: Verify ChangeLogEntries
105
105
```
106
106
107
-
##[error]Invalid date [ 2025-06-23 ]. The date for the changelog being released must be the latest in the file.
108
-
109
107
Any idea why? Seems like a tool bug to me.
110
108
111
109
## answer
112
110
The error occurred because the changelog entry for version `1.0.0b13 (Unreleased)` was added without updating the `_version.py` file. the tool gets the version from there and tries to validate the change log entry for that version. In this case it sees that version isn't the latest version in the changelog and complains (granted the error message could be better). However, the version update is what is missing. Also, looks like a lot of version increment PRs have been getting ignored. It might be worth taking these PR and then pulling them into your feature branches. However if you don't plan to use them then just close them.
0 commit comments