msyyc · msyyc · Aug 7, 2025 · Aug 5, 2025 · Aug 5, 2025 · Aug 5, 2025
diff --git a/QA/python-0529.md b/QA/python-0529.md
diff --git a/QA/python-0626.md b/QA/python-0626.md
@@ -11,7 +11,7 @@ azure/ai/agents/aio/operations/_operations.py:4090: [R0914(too-many-locals), Age
 azure/ai/agents/aio/operations/_operations.py:4475: [R0914(too-many-locals), AgentsClientOperationsMixin.update_agent] Too many local variables (27/25)
 azure/ai/agents/aio/operations/_operations.py:4815: [R0914(too-many-locals), AgentsClientOperationsMixin.create_thread_and_run] Too many local variables (32/25)
 azure/ai/agents/aio/operations/_operations.py:26: [W0611(unused-import), ] Unused import urllib.parse
- 
+
 The _operations.py is straightly created by code gen.  Need advise how to fix them..
 
 ## answer
@@ -41,18 +41,24 @@ This should address the `too-many-locals` and `unused import urllib.parse` warni
 Hi Language - Python,
 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
 The pr checks were successfull…
+```
+_ ERROR collecting sdk/healthinsights/azure-healthinsights-cancerprofiling/tests/test_cancer_profiling.py _
+ImportError while importing test module '/mnt/vss/_work/1/s/sdk/healthinsights/azure-healthinsights-cancerprofiling/tests/test_cancer_profiling.py'.
+Hint: make sure your test modules/packages have valid Python names.
+Traceback:
+.tox/mindependency/lib/python3.13/site-packages/azure/core/rest/__init__.py:27: in <module>
+    from ._rest_py3 import (
+.tox/mindependency/lib/python3.13/site-packages/azure/core/rest/_rest_py3.py:40: in <module>
+    from ._helpers import (
+.tox/mindependency/lib/python3.13/site-packages/azure/core/rest/_helpers.py:28: in <module>
+    import cgi
+E   ModuleNotFoundError: No module named 'cgi'
+```
 
 ## answer
-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.
-
-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.
-
-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.
+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.
 
-If `azure-healthinsights-cancerprofiling` is deprecated and not going to be released again, we should follow the deprecation process as outlined here:
-https://github.com/Azure/azure-sdk-for-python/blob/main/doc/deprecation_process.md
-
-If we might need to release it again someday, we should fix the dependencies to keep it from falling into bitrot.
+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`.
 
 # Testing SDK PRs
 
@@ -88,4 +94,11 @@ Once this PR passes:
 https://github.com/Azure/azure-sdk-for-python/pull/41724
 
 You can pull from main and try regenerating. Let me know if you see any diffs in regeneration and if these diffs work out for you.
-
+
+# Releasing Python SDK
+
+## question
+Hello Language - Python, I wanted to release a new version of my team's SDK in GA using the release planner, I wanted to ask if I had to manually run the ADO pipeline for it here (Run release SDK pipeline)[https://eng.ms/docs/products/azure-developer-experience/develop/sdk-release/sdk-release-pipeline]
+
+## answer
+Since this is an ARM service, you should talk to Yuchao about the process
diff --git a/QA/python-0703.md b/QA/python-0703.md
@@ -37,7 +37,7 @@ The recommended approach is to create a custom error format class like:
 class BatchErrorFormat(ODataV4Format):
     # Custom parsing logic here
 ```
-Then, wrap the operation call like this:
+Then, wrap the operation calls like this:
 ```
 try:
    generated_client.op()
@@ -56,26 +56,22 @@ class BatchExceptionPolicy:
         except HttpResponseError as err:
             raise HttpResponseError(response=err.response, model=err.model, error_format=BatchErrorFormat) from err
 ```
-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.
+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
 
 # pipeline got stuck
 
 ## question 
 Hello,
-   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?
+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?
 [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)
 
 ## answer
-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:
+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.
 
-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.
-
-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.
-
-If you're trying to maintain the PR build pattern, here's a recommended approach:
-
-Get your release branch to the desired state, excluding changelog and version updates.
-Submit a PR targeting your release branch that includes the changelog and version updates.
-The PR build will use the merge commit from both branches in the python - pullrequest pipeline, avoiding conflicts with main.
-Once merged, your release branch will be in its final state, and you can queue the release build.
-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.
+Yet if you want to maintain the PR build pattern. I do have a recommendation how you can make that work with release branches.
+
+1. Get your release branch where you want it to be minus `changelog` and `version` updates.
+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`.
+3. Merge that. Your release branch will be in final state, which you can queue the release build for.
+
+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
diff --git a/QA/python-0710.md b/QA/python-0710.md
@@ -2,7 +2,7 @@
 
 ## question 
 Hello Language - Python
- 
+
 I have code gen generated
 ```
 class AgentsClientOperationsMixin(
@@ -18,3 +18,25 @@ The AgentsClientOperationsMixin class should not be documented or publicly expos
 After discussion, the Python SDK team concluded that the correct solution is to make the mixin operation group a private class. This change ensures the class is hidden from public documentation while maintaining compatibility with the generated code.
 
 The issue has been tracked in https://github.com/microsoft/typespec/issues/7803, and the fix has been implemented in https://github.com/microsoft/typespec/pull/7817.
+
+# Entitlement Required for SDK Generation Pipeline Access
+
+## question 
+Hi team,
+
+I'm currently working on generating the Python SDK using the pipeline: (Using the SDK generation pipelines)[https://eng.ms/docs/products/azure-developer-experience/develop/sdk-generation-pipelines]. Although I have write access to the related GitHub repositories, I’m unable to access the pipeline itself.
+Could you please let me know which entitlement is required for this access? Thank you!
+
+## answer
+https://aka.ms/azsdk/access
+```
+You'll need a GitHub account to contribute to Azure REST API and SDK repositories. Before you get started, be sure that you also:
+
+Join the Microsoft organization on GitHub.
+Join the Azure organization.
+Check the visibility of your Microsoft and Azure org memberships.
+
+If you're working on branches in the main repo for your spec, or working in the Azure SDK repositories to submit pull requests or serving as the support contact for issues, you'll need write access so that you can apply or dismiss labels, create or modify issues, and assign issues to others. It also allows you to add/update test recordings in the test assets repo.
+
+To get access to Azure SDK repos, request to join the (Azure SDK Partners)[https://aka.ms/azsdk/join/azuresdkpartners] and have the request approved by your manager. After your manager approves, it may take up to one day for you to automatically be added to the (azure-sdk-partners)[https://github.com/orgs/Azure/teams/azure-sdk-partners] GitHub team. This will get you write access to all Azure SDK related repos. These membership requests will need to be renewed every 180 days.
+```
diff --git a/QA/python-0717.md b/QA/python-0717.md
@@ -1,8 +1,6 @@
-# API View Displays Incorrect Python Package Name
-
 ## question 
 Hi team,
- 
+
 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:
 `azure_ai_language_text-1.0.0b1-py3-none-any.whl`
 But I noticed that in the previous version api view, the Python namespace only show simplified verison like this :
@@ -11,26 +9,25 @@ Should I manually modify the package name before uploading it to api view, or is
 
 ## answer
 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)
- 
+
 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.
 
 # Python Live Test for async api
 
 ## question 
 Hello Language - Python,
- 
+
 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?
- 
+
 ```
         except aiohttp.client_exceptions.ClientError as err:
 >           raise ServiceRequestError(err, error=err) from err
 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)')]
-```
-
+
 C:\Users\v-dharmarajv\AppData\Local\Programs\Python\Python313\Lib\site-packages\azure\core\pipeline\transport\_aiohttp.py:364: ServiceRequestError
+```
 
 ## answer
 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.
 
 To run live tests, make sure AZURE_TEST_RUN_LIVE is set to "true". If you also want to record, avoid setting AZURE_SKIP_LIVE_RECORDING. As a workaround for the SSL issue, set the environment variable PROXY_URL to http://localhost:5000 instead of using HTTPS. This bypasses certificate validation and resolves the issue.
-
diff --git a/QA/python-0724.md b/QA/python-0724.md
@@ -83,12 +83,12 @@ I've checked my Python installation `ensurepip` is satisfied, tried manually del
 But the issue still persists. Has anyone encountered this before or could share some insights? Any help would be much appreciated. Thank you!
 
 ## answer
-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.
+Maybe you could try install "uv" (here is guidance [Installation | uv](https://docs.astral.sh/uv/getting-started/installation/)) as a workaround and sync with latest main branch of python sdk repo then try again. I have created an issue ([python] install failure with `pip` · Issue #8113 · microsoft/typespec)[https://github.com/microsoft/typespec/issues/8113] to track it.
 
-# "The date for the changelog being released must be the latest in the file."
+# The date for the changelog being released must be the latest in the file.
 
 ## question 
-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  :
+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":
 ```
 [debug]Verifying as a release build because the changelog entry has a valid date.
 ##[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
 Finishing: Verify ChangeLogEntries
 ```
 
-##[error]Invalid date [ 2025-06-23 ]. The date for the changelog being released must be the latest in the file.
-
 Any idea why? Seems like a tool bug to me.
 
 ## answer
 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.
-