Skip to content

feat: Publish to PyPI#53

Open
etowahadams wants to merge 8 commits intoTimoLassmann:mainfrom
etowahadams:etowahadams/pypi
Open

feat: Publish to PyPI#53
etowahadams wants to merge 8 commits intoTimoLassmann:mainfrom
etowahadams:etowahadams/pypi

Conversation

@etowahadams
Copy link

The PR improves aims to make kalign publishable to PyPI. It adds a publishing workflow and makes the python kalign CLI work reliably. I have done my own test publish to TestPyPI to make sure it works. You can test it out using

pip install -i [https://test.pypi.org/simple/](https://test.pypi.org/simple/) --extra-index-url [https://pypi.org/simple](https://pypi.org/simple) kalign-test

Changes

  • Replaced the kalign console script implementation to run the Python bindings directly (instead of shelling out to a separately-installed kalign binary, which could recurse into itself after pip install). (python-kalign/cli.py:1)
  • Made kalign.__version__ resolve from installed distribution metadata to avoid version drift. (python-kalign/__init__.py)
  • Updated packaging metadata:
    • Use README-python.md for PyPI long description.
    • Use SPDX license = "GPL-3.0-or-later", include COPYING via license-files, and removed the deprecated License :: classifier to satisfy modern metadata validation. (pyproject.toml)
  • CI workflow updates:
    • Added a workflow_dispatch input to optionally publish to TestPyPI using TEST_PYPI_API_TOKEN.
    • Pinned macOS runners to macos-14 to avoid delocate failures with libomp built for macOS 15.
    • Made wheel install test detect the dist name from wheel filenames (works for forks/renamed dists like kalign-test). (.github/workflows/wheels.yml:1)
  • Added CLI smoke tests. (tests/python/test_cli.py)
  • Documented release + TestPyPI testing instructions. (README.md:245)

Let me know how it looks @TimoLassmann, and if you have any other recommendations! Thanks again for being open for a contribution like this.

I believe on your end once everything behaves as expected, you will have to make a PyPI account and add your token to the github repository secrets so that the PYPI_API_TOKEN variable will be set in the workflow. I added instructions in the README about how to cut a new release in this workflow.

cc: @jnwei, @jandom

Comment on lines +254 to +260
2) Sanity check locally (recommended)
```bash
python -m venv .venv
source .venv/bin/activate
python -m pip install -U pip build twine
python -m build
twine check dist/*
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good docks

Comment on lines +16 to +20
def test_cli_align_fasta_to_stdout() -> None:
repo_root = Path(__file__).resolve().parents[2]
input_fasta = repo_root / "tests" / "data" / "tiny.fa"

result = subprocess.run(
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good test

user: __token__
password: ${{ secrets.PYPI_API_TOKEN }}
packages_dir: dist/ No newline at end of file
password: ${{ secrets.TEST_PYPI_API_TOKEN }}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'secrets' good

if: env.PYPI_API_TOKEN != ''
with:
user: __token__
password: ${{ env.PYPI_API_TOKEN }}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should really be a secret, no?

One pattern to take is to have two secrets

  • PYPI_API_TOKEN
  • TEST_PYPI_API_TOKEN

And use the an input to decide which secret to read

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants