Skip to content

Prepare DSF for PyPI release #8

Description

@nikosarcevic

Goal

Prepare DSF for an initial PyPI release once we are confident that the core data-vector and covariance calculations have been benchmarked against existing reference implementations.

This issue is not about releasing immediately. It is about collecting the remaining packaging, documentation, testing, and validation steps needed before publishing DSF to PyPI.

Scope

Before publishing DSF, we should make sure the package is scientifically and technically ready for a first public release.

The main requirements are:

  1. Benchmarks are in place

    • Data-vector benchmarks should compare DSF $\Delta\Sigma(R)$ predictions against Ben’s old code and Manon’s code.
    • Covariance benchmarks should compare the DSF covariance calculation against the Dani Leonard et al. legacy implementation.
    • Any known convention differences should be documented.
  2. Tests are passing

    • Unit tests should pass locally.
    • CI should pass on GitHub.
    • Core data-vector and covariance functionality should have basic test coverage.
    • Import tests should confirm that the installed package works outside the source tree.
  3. Documentation is ready enough for users

    • The docs should include a short installation page.
    • The docs should include at least one basic $\Delta\Sigma$ data-vector example.
    • The docs should include a short covariance example or note if covariance is still experimental.
    • The README should clearly explain what DSF does and what is still under development.
  4. Packaging metadata is complete

    Check that pyproject.toml includes:

    • package name
    • description
    • authors
    • license
    • Python version requirement
    • runtime dependencies
    • optional development dependencies
    • project URLs, e.g. docs and GitHub repository
  5. Release workflow is ready

    • Decide whether to publish manually or through GitHub Actions.
    • If using GitHub Actions, set up PyPI Trusted Publishing.
    • Add a release checklist for tagging versions.
    • Confirm that source distribution and wheel can be built cleanly.

Suggested checks

Before publishing, run:

python -m pip install -e ".[dev]"
pytest
python -m build
twine check dist/*

Also test a clean install from the built wheel, ideally in a fresh environment.

Acceptance criteria

  • Data-vector benchmark issue is completed or explicitly accepted as sufficient for first release.
  • Covariance benchmark issue is completed or covariance is clearly marked as experimental.
  • CI passes on main.
  • Unit tests pass locally.
  • Package builds successfully with python -m build.
  • Built distributions pass twine check dist/*.
  • README includes installation instructions.
  • Docs include at least one basic data-vector example.
  • Docs include either a covariance example or a clear note about covariance status.
  • Package metadata in pyproject.toml is complete.
  • Versioning strategy is decided.
  • PyPI publishing method is decided: manual upload or GitHub Actions trusted publishing.
  • First release tag is created only after the above checks are done.

Notes

We should wait to publish to PyPI until the benchmark issues are in good shape. It is fine if the first release is still early-development, but the package should not look like an unvalidated scientific tool. The first PyPI release should communicate clearly what is stable, what has been benchmarked, and what is still experimental.

Metadata

Metadata

Assignees

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