Merge branch 'microsoft:main' into main

Author: MaiLinhP

.chronus/changes/copilot-fix-enum-name-compile-error-2026-3-16-5-51-48.md

@@ -0,0 +1,7 @@
+---
+changeKind: fix
+packages:
+  - "@typespec/http-client-python"
+---
+
+Fix enum member names with hyphens generating invalid Python identifiers

.chronus/changes/python-addBackApiViewSphinx-2026-3-9-12-35-1.md

@@ -0,0 +1,7 @@
+---
+changeKind: internal
+packages:
+  - "@typespec/http-client-python"
+---
+
+Add apiview and sphinx to ci

.github/skills/emitter-prep-for-pr/SKILL.md

@@ -12,7 +12,7 @@ description: >
 # Emitter Prep for PR
 
 Prepares language emitter changes for pull request by running build/format/lint,
-creating a changeset with an appropriate message, and pushing to the remote branch.
+checking for a changeset, and pushing to the remote branch.
 
 **This skill is for language emitter packages only:**
 
@@ -24,276 +24,121 @@ Do NOT use this skill for core TypeSpec packages (compiler, http, openapi3, etc.
 
 ## Workflow
 
-### Step 1: Identify changed language emitter packages
+### Step 1: Determine the emitter package
 
-Determine which language emitter packages have changes:
+Figure out which emitter package the user is working on from context (cwd, recent
+changes, or ask). The package will be under `packages/<package-name>/`.
 
-```bash
-cd ~/Desktop/github/typespec
-
-# Compare against upstream/main (microsoft/typespec) if available, otherwise main
-BASE_BRANCH=$(git rev-parse --verify upstream/main 2> /dev/null && echo "upstream/main" || echo "main")
-
-# Filter for language emitter packages only
-git diff "$BASE_BRANCH" --name-only | grep "^packages/http-client-" | cut -d'/' -f2 | sort -u
-```
-
-This filters for `http-client-python`, `http-client-csharp`, `http-client-java`, etc.
-
-### Step 2: Validate each changed emitter package
-
-For each changed emitter package (e.g., `http-client-python`, `http-client-csharp`, `http-client-java`):
+### Step 2: Build, format, and lint the emitter package
 
 ```bash
 cd ~/Desktop/github/typespec/packages/PACKAGE_NAME
 
 # Build
 npm run build
-if [ $? -ne 0 ]; then
-  echo "Build failed for PACKAGE_NAME"
-  exit 1
-fi
 
-# Format
+# Format (includes both TypeScript and Python formatting)
 npm run format
-if [ $? -ne 0 ]; then
-  echo "Format failed for PACKAGE_NAME"
-  exit 1
-fi
 
-# Lint (if available)
-npm run lint 2> /dev/null || echo "No lint script for PACKAGE_NAME"
+# Lint (emitter-only is fine for quick validation)
+npm run lint -- --emitter
 ```
 
-If any step fails, report the error and stop. Do not proceed to changeset.
-
-### Step 3: Run format and spell check at repo root
+If any step fails, report the error and stop. Do not proceed.
 
-After validating individual packages, run format and spell check at the repo root:
+### Step 3: Run format at repo root
 
 ```bash
 cd ~/Desktop/github/typespec
-
-# Format all files
 pnpm format
-
-# Spell check
-pnpm cspell
 ```
 
-If spell check fails, either fix the typos or add words to the cspell dictionary.
+**Important:** `pnpm format` may touch files outside the emitter package (e.g.,
+`.devcontainer/`, other packages). When staging changes in Step 6, **only stage
+files within the emitter package directory** (`packages/PACKAGE_NAME/`) and
+`.chronus/changes/` and `.github/skills/`. Discard any formatting changes to
+unrelated files with `git checkout -- <file>`.
 
-### Step 4: Analyze changes for changeset message
+### Step 4: Check for existing changeset
 
-Examine the changes to determine an appropriate changeset message:
+Check if a changeset already exists for the current branch:
 
 ```bash
 cd ~/Desktop/github/typespec
-
-# Determine base branch
-BASE_BRANCH=$(git rev-parse --verify upstream/main 2> /dev/null && echo "upstream/main" || echo "main")
-
-# Get commit messages on this branch
-git log "$BASE_BRANCH"..HEAD --oneline
-
-# Get changed files
-git diff "$BASE_BRANCH" --name-only
-
-# Get the actual code changes (for understanding intent)
-git diff "$BASE_BRANCH" --stat
+BRANCH=$(git rev-parse --abbrev-ref HEAD)
+ls .chronus/changes/ | grep -i "$BRANCH" || echo "NO_CHANGESET"
 ```
 
-### Step 5: Determine changeset parameters
-
-Based on the changes, determine:
-
-1. **changeKind** - one of:
-   - `internal` - Internal changes not user-facing (tests, docs, refactoring)
-   - `fix` - Bug fixes (patch version bump)
-   - `feature` - New features (minor version bump)
-   - `deprecation` - Deprecating existing features (minor version bump)
-   - `breaking` - Breaking changes (major version bump)
-   - `dependencies` - Dependency bumps (patch version bump)
+- If a changeset **exists**: Skip to Step 6 (no need to create one).
+- If **NO_CHANGESET**: Proceed to Step 5 to create one.
 
-2. **packages** - affected packages, e.g.:
-   - `@typespec/http-client-python`
-   - `@typespec/http-client-csharp`
-   - `@typespec/http-client-java`
+### Step 5: Create changeset (only if none exists)
 
-3. **message** - concise description of the change
+Ask the user what kind of change this is, or infer from context:
 
-### Step 6: Create changeset file
+1. **changeKind** - one of: `internal`, `fix`, `feature`, `deprecation`, `breaking`, `dependencies`
+2. **message** - concise user-focused description
 
-Create a changeset file in `.chronus/changes/`:
+Then create the file:
 
 ```bash
 cd ~/Desktop/github/typespec
-
-# Generate filename with timestamp
+BRANCH=$(git rev-parse --abbrev-ref HEAD)
 TIMESTAMP=$(date +"%Y-%m-%d-%H-%M-%S")
-FILENAME=".chronus/changes/BRANCH_NAME-${TIMESTAMP}.md"
+FILENAME=".chronus/changes/${BRANCH}-${TIMESTAMP}.md"
+```
 
-cat > "$FILENAME" << 'EOF'
+```markdown
 ---
 changeKind: <KIND>
 packages:
   - "<PACKAGE>"
 ---
 
 <MESSAGE>
-EOF
-```
-
-### Step 7: Show changes and prompt user
-
-Display all changes to the user:
-
-```bash
-cd ~/Desktop/github/typespec
-git status
-git diff --stat
 ```
 
-Then use AskUserQuestion to confirm:
-
-- Show the changeset that will be added
-- Show the files that will be committed
-- Show which remote will be used: "Will push to `origin`"
-- Ask: "Do these changes look good to push to origin?"
-
-Options:
-
-- "Yes, push to origin" - proceed with commit and push to origin
-- "Push to different remote" - ask which remote to use instead
-- "Edit changeset" - let user modify the changeset message/kind
-- "Cancel" - abort without pushing
-
-If user selects "Push to different remote", ask which remote name to use and push to that instead of origin.
-
-### Step 8: Commit and push (if approved)
-
-If user approves, commit the changes:
+### Step 6: Stage, commit, and push
 
 ```bash
 cd ~/Desktop/github/typespec
-
-# Stage all changes
 git add -A
-
-# Commit with descriptive message
-git commit -m "$(
-  cat << 'EOF'
-<COMMIT_MESSAGE>
-
-Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
-EOF
-)"
+git status
 ```
 
-Then push to the user's fork. **Default to `origin`**, but if the user specified a different remote, use that instead:
+Show the user what will be committed and ask for confirmation. Then:
 
 ```bash
-# Get current branch name
 BRANCH=$(git rev-parse --abbrev-ref HEAD)
+git commit -m "<COMMIT_MESSAGE>
 
-# Push to origin by default (or user-specified remote)
-git push -u origin "$BRANCH"
-```
-
-### Asking about remote
-
-When prompting the user in Step 7, include the remote that will be used:
-
-- Show: "Will push to `origin` (your fork)"
-- If the user says to use a different remote (e.g., "push to `my_fork`"), use that instead
-
-**Important:** Never push directly to the `microsoft/typespec` remote (usually named `upstream`).
-
-## Changeset Message Guidelines
-
-Write changeset messages that are:
+Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>"
 
-1. **User-focused** - Describe the impact on users, not implementation details
-2. **Concise** - One sentence, starting with a verb (Add, Fix, Update, Remove)
-3. **Specific** - Mention the feature/fix clearly
-
-### Examples by changeKind:
-
-**internal:**
-
-- "Refactor namespace resolution logic for clarity"
-- "Add mock API tests for paging scenarios"
-- "Update development tooling and skills"
-
-**fix:**
-
-- "Fix incorrect deserialization of nullable enum properties"
-- "Fix client initialization when using custom endpoints"
-
-**feature:**
+# Always push to origin (user's fork), never upstream
+git push origin "$BRANCH"
+```
 
-- "Add support for XML serialization in request bodies"
-- "Add `@clientOption` decorator for customizing client behavior"
+## Changeset Guidelines
 
-**deprecation:**
+### changeKind reference
 
-- "Deprecate `legacyMode` option in favor of `compatibilityMode`"
+- **internal**: Tests, CI/CD, refactoring, docs, skills — not user-facing
+- **fix**: Bug fixes users would notice
+- **feature**: New user-facing capabilities
+- **deprecation**: Marking something as deprecated
+- **breaking**: Removing or changing behavior incompatibly
+- **dependencies**: Dependency version bumps
 
-**breaking:**
+### Message examples
 
-- "Remove deprecated `v1` client generation mode"
-- "Change default serialization format from XML to JSON"
+- `internal`: "Improve CI pipeline performance and test infrastructure"
+- `fix`: "Fix incorrect deserialization of nullable enum properties"
+- `feature`: "Add support for XML serialization in request bodies"
 
-## Language Emitter Package Names
+### Package names
 
 | Folder               | Package Name                   |
 | -------------------- | ------------------------------ |
 | `http-client-python` | `@typespec/http-client-python` |
 | `http-client-csharp` | `@typespec/http-client-csharp` |
 | `http-client-java`   | `@typespec/http-client-java`   |
-
-## Notes
-
-### When to use each changeKind
-
-- **internal**: Tests, documentation, refactoring, CI/CD changes, skill updates
-- **fix**: Bug fixes that users would notice
-- **feature**: New capabilities users can use
-- **deprecation**: Marking something as deprecated (still works, but discouraged)
-- **breaking**: Removing or changing behavior in incompatible ways
-
-### Multiple packages
-
-If changes affect multiple packages **with the same change kind**, list all of them in a single changeset:
-
-```yaml
-packages:
-  - "@typespec/http-client-python"
-  - "@typespec/http-client-csharp"
-```
-
-**If packages have different change kinds, create separate changeset files for each.** For example, if the PR adds a feature to `@typespec/http-client-python` and fixes a bug in `@typespec/http-client-csharp`, create two files:
-
-```yaml
-# File 1: feature for python
-changeKind: feature
-packages:
-  - "@typespec/http-client-python"
-```
-
-```yaml
-# File 2: fix for csharp
-changeKind: fix
-packages:
-  - "@typespec/http-client-csharp"
-```
-
-### Skipping changeset
-
-Some changes don't need a changeset:
-
-- Changes only to `.github/skills/` (CI will allow this)
-- Changes only to test files (if marked in `changedFiles` config)
-- Changes only to markdown files (if marked in `changedFiles` config)
-
-Check `.chronus/config.yaml` for `changedFiles` patterns that are excluded.

.gitignore

@@ -233,7 +233,10 @@ packages/http-client-python/tests/**/cadl-ranch-coverage.json
 !packages/http-client-python/package-lock.json
 packages/http-client-python/micropip.lock
 packages/http-client-python/venv_build_wheel/
+packages/http-client-python/tests/**.json
 
 # http-server-js emitter
 packages/http-server-js/test/e2e/generated
 .pnpm-store/
+packages/http-client-python/tests/.uv-cache/
+packages/http-client-python/tests/.wheels/

packages/http-client-csharp/generator/TestProjects/Spector.Tests/Http/Payload/Xml/XmlTests.cs

@@ -390,6 +390,18 @@ public Task GetModelWithDatetime() => Test(async (host) =>
             Assert.AreEqual(DateTimeOffset.Parse("Fri, 26 Aug 2022 14:38:00 GMT"), model.Rfc7231);
         });
 
+        [SpectorTest]
+        public Task PutModelWithDatetime() => Test(async (host) =>
+        {
+            var model = new ModelWithDatetime(
+                DateTimeOffset.Parse("2022-08-26T18:38:00Z"),
+                DateTimeOffset.Parse("Fri, 26 Aug 2022 14:38:00 GMT"));
+            var response = await new XmlClient(host, null).GetModelWithDatetimeValueClient()
+                .PutAsync(model);
+
+            Assert.AreEqual(204, response.GetRawResponse().Status);
+        });
+
         [SpectorTest]
         public Task GetXmlErrorValue() => Test((host) =>
         {