From 62c38729ecc0a9195d7fd4ebb22468e6a804840b Mon Sep 17 00:00:00 2001 From: Copilot <223556219+Copilot@users.noreply.github.com> Date: Wed, 29 Jul 2026 21:01:41 -0700 Subject: [PATCH 1/2] MAINT: Point docs site at v1.0.1 Release-metadata follow-up for the v1.0.1 patch release (step 10 of doc/contributing/10_release_process.md): - Bump `default:` and `stable:` from 1.0.0 to 1.0.1 so the site root and the /stable/ alias serve the latest release. - Replace the `1.0.0` entry under `versions:` with `1.0.1` (ref releases/v1.0.1) instead of listing both. Note on replace-vs-add-both: the file already lists 0.12.1 but not 0.12.0, so superseded patch versions do not appear to be kept in the picker. That precedent is suggestive but not conclusive -- the file was seeded with 0.12.1 already present, so it never demonstrably went through an add-then-replace cycle. If you would rather keep both 1.0.0 and 1.0.1 in the picker, re-add the 1.0.0 entry during review. Validated with build_scripts/resolve_docs_matrix.py, the same script .github/workflows/docs.yml uses to derive the build matrix. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: a008124c-220e-491c-9ea1-2144867ba53d --- .github/docs-versions.yml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/.github/docs-versions.yml b/.github/docs-versions.yml index 0091b53d60..264024d9a3 100644 --- a/.github/docs-versions.yml +++ b/.github/docs-versions.yml @@ -8,16 +8,16 @@ # To add a new release version: append an entry under `versions:`, and update # `default:` / `stable:` if the new release should become the landing page. -default: "1.0.0" # served at the site root (microsoft.github.io/PyRIT/) -stable: "1.0.0" # served at /stable/ and shown as "(stable)" in the picker +default: "1.0.1" # served at the site root (microsoft.github.io/PyRIT/) +stable: "1.0.1" # served at /stable/ and shown as "(stable)" in the picker versions: - slug: latest name: "latest (dev, main)" ref: main - - slug: "1.0.0" - name: "1.0.0" - ref: releases/v1.0.0 + - slug: "1.0.1" + name: "1.0.1" + ref: releases/v1.0.1 - slug: "0.14.0" name: "0.14.0" ref: releases/v0.14.0 From 215f75afb04a7263659ce4759483403252e91181 Mon Sep 17 00:00:00 2001 From: Copilot <223556219+Copilot@users.noreply.github.com> Date: Wed, 29 Jul 2026 21:02:02 -0700 Subject: [PATCH 2/2] FIX: Prevent UnicodeEncodeError in prepare_package.py on Windows On Windows, Python encodes sys.stdout with the legacy ANSI code page (cp1252) whenever stdout is not a true Win32 console -- piped, redirected, or captured by CI. The script prints non-ASCII status glyphs (U+2713, U+274C, U+2705) that cp1252 cannot represent, so the print raises UnicodeEncodeError. Observed failure: `uv run python build_scripts/prepare_package.py` crashed on `print("\u2713 Dependencies installed")` right after npm install had succeeded. The exception propagated out of build_frontend() and killed main(), so the copy step never ran and pyrit/backend/frontend was never populated -- a decorative character turned a working build into a hard failure. The failure-path prints are worse still: a genuine frontend build error would have been masked by an unrelated encoding traceback. Reconfigure stdout/stderr to UTF-8 with errors="replace" at the start of main(), guarded for streams that are None (pythonw) or lack reconfigure(). This keeps the glyphs rather than downgrading them to ASCII markers, and fixes every affected print at once. Verified on Windows with stdout piped and no PYTHONUTF8/PYTHONIOENCODING set: sys.stdout.encoding is cp1252 before the call and utf-8 after, all six glyph messages emit cleanly, and an A/B run of main() with the new helper stubbed out reproduces the original UnicodeEncodeError. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: a008124c-220e-491c-9ea1-2144867ba53d --- build_scripts/prepare_package.py | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/build_scripts/prepare_package.py b/build_scripts/prepare_package.py index 4be8b5e38c..83f81ee83b 100644 --- a/build_scripts/prepare_package.py +++ b/build_scripts/prepare_package.py @@ -6,12 +6,30 @@ This builds the TypeScript/React frontend and copies artifacts into the Python package structure. """ +import contextlib import shutil import subprocess import sys from pathlib import Path +def _configure_utf8_stdio() -> None: + """ + Force UTF-8 encoding on stdout/stderr so status glyphs cannot abort the build. + + On Windows, Python encodes standard output with the legacy ANSI code page (e.g. cp1252) + whenever it is not attached to a console -- piped, redirected, or captured by CI. The + non-ASCII status characters printed below are not representable there, so the print + raises ``UnicodeEncodeError`` and a purely decorative character fails the build. + """ + for stream in (sys.stdout, sys.stderr): + reconfigure = getattr(stream, "reconfigure", None) + if reconfigure is None: + continue + with contextlib.suppress(OSError, ValueError): + reconfigure(encoding="utf-8", errors="replace") + + def build_frontend(frontend_dir: Path) -> bool: """ Build the TypeScript/React frontend using npm. @@ -116,8 +134,10 @@ def copy_frontend_to_package(frontend_dist: Path, backend_frontend: Path) -> boo return False -def main(): +def main() -> int: """Build frontend and prepare package for distribution.""" + _configure_utf8_stdio() + # Define paths root = Path(__file__).parent.parent frontend_dir = root / "frontend"