PyPI deployment (so micro-sam can be listed on napari-hub)

[GenevieveBuckley]

Closes https://github.com/computational-cell-analytics/micro-sam/issues/530

The napari-hub discovers napari plugins by scraping PyPI, looking for the napari framework classifier. When it finds a package with the napari classifier, it will automatically populate a page on the napari-hub for that plugin.

This PR:

• Adds a deploy job to the release_drafter.yml github workflow. This job runs every time the release drafter workflow runs and the update_release_draft job finishes.
• Updates requirements-dev.txt to include build and twine dependencies (this is not required for the release_drafter.yml action to work, but they are nice to have if you are testing the build locally)
• Adds a section to the installation docs, discouraging users from installing micro-sam with pip. As previously discussed here and here, if users pip install micro-sam then not all of the dependencies will be correctly installed. Some of our dependencies, like affogato are only available from conda-forge. However, we think the benefit of being searchable on napari-hub outweighs this downside.

Still to do: @constantinpape will need to

• [ ] Set up an API token for PyPI, see https://pypi.org/help/#apitoken
• [ ] Add the token as github secrets named PYPI_USERNAME and PYPI_PASSWORD in the settings of this repository, see https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-a-repository

[GenevieveBuckley]

I have added secrets for PYPI_USERNAME and PYPI_PASSWORD now. Can we test if it works in the PR or should I go ahead and merge it?

It might be simplest to merge it, and then try a v1.0.2rc1 release. I think we should try that first.

[GenevieveBuckley]

More options: If that doesn't work as expected and we need more involved debugging, then we could do that using the Test PyPI server. Test PyPI is totally separate from the real PyPI, so you need to make a separate account and make separate API tokens for it.

pypi_test_upload script (click to expand)

```yaml name: pypi_test_upload on: workflow_dispatch: # manual triggers with workflow_dispatch only work *after* the workflow is merged into the main repository branch permissions: contents: read jobs: deploy: # This will upload a Python Package using Twine when a release is created # For more information see: https://help.github.com/en/actions/language-and-framework-guides/using-python-with-github-actions#publishing-to-package-registries # # This job will run when you have tagged a commit, starting with "v*" # or created a release in GitHub which includes a tag starting with "v*" # and requires that you have put your twine API key in your # github secrets (see readme for details) needs: [] runs-on: ubuntu-latest if: contains(github.ref, 'tags') steps: - uses: actions/checkout@v4 - name: Set up Python uses: actions/setup-python@v5 with: python-version: '3.x' - name: Install dependencies run: | python -m pip install --upgrade pip python -m pip install build twine - name: Build and publish env: TWINE_USERNAME: ${{ secrets.TEST_PYPI_USERNAME }} TWINE_PASSWORD: ${{ secrets.TEST_PYPI_PASSWORD }} run: | python -m build twine upload --repository testpypi dist/* ```

I made this test workflow. Essentially it's a copy of the new part of this PR, aimed at Test PyPI using TEST_PYPI_USERNAME/TEST_PYPI_PASSWORD and twine upload --repository testpypi dist/*

But I found out you can only manually trigger github actions with workflow_dispatch after it is merged into the main branch. It's also being skipped when I add "on push" or "on pull_request" triggers, but maybe that's because I am trying to run it from my own fork.

[constantinpape]

Thanks for the feedback! I will go ahead and merge this later, then create a new post release to check if it works.