py-shiny-release

Guides the full Shiny for Python ecosystem release train through thirteen interactive phases.

1.8k|134|Updated Jul 27, 2021
One-click install
npx skills add https://github.com/posit-dev/py-shiny --skill py-shiny-release
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: py-shiny-release
Source: https://github.com/posit-dev/py-shiny/tree/main/.claude/skills/py-shiny-release
Command: npx skills add https://github.com/posit-dev/py-shiny --skill py-shiny-release

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires playwright, and includes references (resource) components.

What problem does it solve?

Releasing Shiny for Python involves coordinating version bumps, CI checks, tagging, PyPI publishing, conda-forge feedstocks, Huggingface, and site updates across nine interdependent repositories, where a single missed step (like a mistitled GitHub Release or a stale PyPI pin) silently breaks downstream packages.

Core Features & Use Cases

  • Interactive 13-phase release train: Walks through py-htmltools, py-shiny, py-shinyswatch, py-shinywidgets, shinylive (JS), py-shinylive, r-shinylive, docs site, conda-forge, Huggingface, and blog post publication with explicit user confirmation gates before any tagging or publishing.
  • Pre-release verification gates: Scans for release-blocking TODO: release markers, checks for git-based dependencies, verifies CI status without truncation, and requires explicit user approval before each publish.
  • Shinylive example testing: Ships a Playwright script that tests all Python shinylive examples against local, github.io, or shinylive.io deployments with cache-busting and parallel batches.
  • Use Case: A maintainer says "start the py-shiny 1.8.0 release" and the Skill drives the entire multi-repo train, catching pitfalls like the shinyswatch TEST title trap, the broken make update_packages_lock, and PyPI index lag.

Quick Start

Start the py-shiny release train for version 1.8.0 and walk me through each phase with confirmation gates.

Frequently Asked Questions about py-shiny-release

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I release a new version of Shiny for Python?

Follow the 13-phase release train: release py-htmltools and py-shiny to PyPI first, then shinyswatch and shinywidgets, then update shinylive JS, py-shinylive, r-shinylive, the docs site, conda-forge, and Huggingface. Each phase ends with a pre-release gate requiring explicit user confirmation before tagging and publishing.

What order should py-shiny ecosystem packages be released in?

Release in dependency order: py-htmltools first, then py-shiny, then py-shinyswatch and py-shinywidgets, followed by shinylive JS, py-shinylive, and r-shinylive. Conda-forge feedstocks must also bump in dependency order because downstream recipe tests import shiny.

Why did my py-shiny package not publish to PyPI after the GitHub Release?

Most repos gate the PyPI publish workflow on the GitHub Release title prefix, so a mistitled release silently skips publishing while the workflow reports success. For py-shinylive, delete only the GH Release object, keep the tag, and recreate it with a title starting with 'shinylive' to re-fire the publish event.

How do I test shinylive examples before deploying?

Run the repo's own examples-smoke-test Playwright suite, which checks the shinylive terminal, app frame, and browser console for errors. The bundled test_shinylive_site.py script is a supplementary check that tests all Python examples against a base URL with cache-busting query params in parallel batches of five.

Does the shinylive lockfile update PyPI-pinned packages automatically?

No. Packages marked with source 'pypi' and version 'latest' in shinylive_requirements.json are carried over verbatim by make all and never re-resolved. Edit the single entry by hand using the repo's pyodide_packages helper, and do not run make update_packages_lock, which is broken.

What are TODO: release markers in the py-shiny repo?

They are greppable comments marking changes that can only be actioned during a release, such as un-pinning a git dependency after an upstream package reaches PyPI. The release cannot complete while any marker is unresolved, and holding PRs must be scanned for their own markers before merging.