Skip to content

Set up automated PyPI publishing for phileas-python (phileas-redact) #50

Description

@jzonthemtn

Summary

Establish a repeatable, automated pipeline that publishes the Phileas Python library (philterd/phileas-python) to PyPI, so new versions ship reliably instead of by hand.

Context

  • The Phileas Python library is distributed on PyPI as phileas-redact. The bare name phileas on PyPI is an unrelated third-party package, so phileas-redact is the canonical install name (pyproject.toml declares name = "phileas-redact").
  • phileas-redact 1.0.0 is already published to PyPI (authored by Philterd, LLC), but publishing appears to be manual: the repo's only workflows are docs.yml and tests.yml, with no release/publish workflow.
  • The documented pip install phileas-redact instruction needs to stay current and trustworthy, so the PyPI package must remain reliably published.

Acceptance Criteria

  • A GitHub Actions workflow in this repo builds the sdist and wheel (python -m build) and publishes them to PyPI.
  • Publishing uses PyPI Trusted Publishing (OIDC), not a long-lived API token. If a token must be used instead, it is a project-scoped token stored as an encrypted Actions secret.
  • The workflow triggers on a published GitHub Release (or a pushed v* tag), so each release is a single, auditable action.
  • Artifacts are validated with twine check before upload.
  • The workflow fails fast if the release version does not match [project].version in pyproject.toml, or if that version already exists on PyPI (no silent overwrite/skip).
  • pyproject.toml metadata is complete for a clean PyPI listing: summary, long description from README.md, Apache-2.0 license, authors, project URLs (homepage, repository, docs), and requires-python (currently >=3.9).
  • A dry run to TestPyPI is documented and succeeds before relying on the production publish.
  • On a clean environment, pip install phileas-redact installs the latest published version and import succeeds on each supported Python version.
  • The release process (bump version, tag, trigger publish) is documented in the repo, e.g. RELEASING.md or CONTRIBUTING.md.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions