Migrate some Python Agent Framework samples to uv

[luyajun0205]

Migrates 18 Python Agent Framework hosted-agent samples from requirements.txt/pip dependency management to pyproject.toml and uv.

Changes

• Replaces requirements.txt with pyproject.toml for each migrated sample.
• Adds committed uv.lock files for reproducible dependency resolution.
• Adds uv.toml with system certificate support.
• Pins uv to 0.11.7.
• Updates Dockerfiles to:
  • use Python 3.13
  • install uv from the official uv container image
  • install dependencies with uv sync --frozen
  • run agents from the uv-managed virtual environment
• Updates README and AGENTS guidance to use uv sync --frozen and
  uv run --no-sync.
• Updates the applicable sample.yaml build and validation commands.

[Wei Meng (m5i-work)]

The move to pyproject.toml + uv.lock is the right direction for preventing samples from silently breaking after dependency releases. The runtime lock graphs appear complete, and I am not requesting that requirements.txt be retained. Policy/checker alignment is covered by #983.

I am requesting changes for the concrete CI failure and the remaining setup/reproducibility gaps noted inline.

Validation evidence: Can we provide Hosted Agent cloud E2E results for the 18 migrated samples against this PR revision, including the applicable code/container deployment paths? The current public generic CI selects only three samples and does not exercise their hosted deployment.

I am not asking for additional sample.yaml coverage—the Hosted Agent E2E suite is the appropriate validation path. Its missing public PR integration is a separate infrastructure follow-up, but we still need validation evidence for this migration.

[Wei Meng (m5i-work)]

Fix the failing CI commands (applies to all three changed sample.yaml files).

The generic validator creates a Python 3.12 .venv, and this build command installs uv inside it. Because the new project requires Python 3.13+, uv sync replaces that environment, deleting the uv executable. The next validate command then fails with uv: command not found. This sequence appears in the caller, executor, and downstream-Azure jobs; for example, the caller log shows:

Using CPython 3.14.4
Removed virtual environment at: .venv
Creating virtual environment at: .venv
uv: command not found

Please install uv outside the environment it manages and align the validation interpreter with the supported Python version. The same installation pattern in the local setup instructions should also be checked.

[luyajun0205]

I updated both Python validation paths to use Python 3.13 and install uv 0.11.7 outside the sample-managed virtual environment via a commit-pinned setup-uv action.

[Wei Meng (m5i-work)]

Update the shared setup guide alongside this deletion.

The leaf READMEs are updated, but the shared samples/python/hosted-agents/agent-framework/README.md still directs users into these migrated sample directories and tells them to run pip install -r requirements.txt or uv pip install -r requirements.txt. Those commands will fail after these files are deleted. It also still documents Python 3.10+, while the new projects require 3.13+.

Please update the shared guide to the frozen uv installation/run flow and matching Python prerequisite. This is not a request to retain requirements.txt; the intentional uv migration should be reflected consistently in the shared instructions.

[luyajun0205]

Updated the README to preserve the existing requirements.txt workflow and add uv as an alternative for environment setup and local execution, since some samples still use the requirements.txt workflow.

[Wei Meng (m5i-work)]

Remove the floating build dependency (applies to all 18 projects).

The runtime dependency graph is locked, but requires = ["setuptools>=77"] introduces a floating build dependency outside uv.lock. The documented local uv sync --frozen installs the editable root project, so its isolated build environment can select a newer setuptools release even when the lockfile is unchanged. Docker's --no-install-project avoids this particular issue, but the documented local sync does not.

Do these script-based samples need to be installed as packages? If not, avoiding project packaging would remove this dependency. Otherwise, please constrain the build dependencies too, so a future build-tool release cannot silently break local setup.

[luyajun0205]

I updated all samples to disable project packaging and regenerated their lockfiles, removing the floating build dependency.

[Wei Meng (m5i-work)]

Include Foundry IQ provisioning in the frozen dependency flow.

This sample's hooks/postprovision.sh and hooks/postprovision.ps1 still run python -m pip install -q requests azure-identity python-dotenv without version constraints, then execute provision_kb.py using the ambient interpreter.

This is an existing path that the migration leaves unlocked: the agent runtime becomes reproducible, but provisioning can still break after a direct or indirect dependency release. Please declare the provisioning dependencies in the uv project or a dependency group and execute the script using the frozen environment.

[luyajun0205]

I updated the provisioning dependencies to use a locked uv group and the frozen uv environment.

[Antriksh Jain (antriksh30)]

please rebase this branch to latest main.