Publish to pypi #59
Merged
Publish to pypi #59
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Disable appending local part to version because we're testing uploads to TestPyPI, and pypi does not support the local part in version numbers (see: https://github.com/pypa/setuptools_scm/#version-number-construction)
This workflow is triggered when publishing a new release using the GitHub Releases functionality. It can also be triggered manually for testing. The workflow will always publish to Test PyPI, but will only publish to the real PyPI, when releasing a new version using the GitHub Releases functionality. The version for the package is generated by setuptools_scm, based on the git tags/commits. For all non-tagged commits, a "dev version" is generated with the format "0.1.2-dev3", where 0.1.2 is the latest tag plus one more in the last part of the version number (i.e. given the last tag was 0.1.1, 0.1.2 will be used for the dev version) and the 3 in "-dev3" comes from the number of commits since the last tag. (This all is standard setuptools_scm behaviour.)
|
Looks good, thanks for working on this. I set up the TEST secret (but no the production one) already, so let's try this... |
|
https://github.com/ThomasWaldmann/py-esp32-ulp/actions/runs/1487382205 https://test.pypi.org/project/micropython-py-esp32-ulp/0.1.0/ of course prod pypi publishing failed due to the missing secret... |
|
Hmm, it seems that I am not owner of the pypi.org project yet, so I can't generate the pypi api token. Ehrm, that doesn't exist yet. And one can't create (specific) tokens for non-existing projects. Update: using a temporary scary global token worked to create the pypi.org project, now replaced that again with a project-specific token. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a GitHub Actions workflow for publishing our upip package to PyPi. It resolves #58.
Overview
I was inspired to create this by this article: https://simonwillison.net/2021/Nov/4/publish-open-source-python-library/, even though I now saw, that GitHub offers a workflow template for this too, using an action from its Actions Marketplace.
Instead of using a hardcoded version number during the build, setup.py now uses setuptools-scm to derive a useful/relevant version from git metadata (tags/commits).
The below is documentation mainly for once the PR has been merged, and for how to then test it and later release 1.0.0.
Setup
The workflow in this PR will require setting up 2 repository secrets (Settings -> Secrets -> Actions secrets -> New repository secret), namely
TEST_PYPI_API_TOKENandPYPI_API_TOKEN(for TestPyPi and real PyPI respectively). These tokens can be generated in TestPyPI and real PyPI as follows:pypi-Once you have the tokens for both TestPyPI and real PyPI, add them as repository secret to the Github repo.
Testing
To test this PR, it sadly needs to be merged to master (or a "dummy" publish.yml must be committed to master), otherwise Github does make this workflow available in the user interface. However, merging to master should be safe, as this workflow is only triggered when creating a release (which is a deliberate step) or by manually triggering the workflow.
Once merged to master, it can be tested by either triggering the workflow manually (a good first step), or by creating a new Release with Github.
PYPI_API_TOKENsecret initially, to prevent accidentally publishing test releases to the live PyPI.0.1-devXwhereXis the number of commits since the last tag (in our case, since the beginning of history, since we have no tags yet)Test-before-publish
The article that inspired me to create this publishing workflow suggested to run the automated tests again as part of the publishing workflow to ensure no untested code is published. I like that idea.
However, I could not find a good way to do that without duplicating the test steps from the existing workflow into the new publish workflow. I tried many ways (see the ideas I tried) and eventually decided to leave this out. Github Actions sadly does not provide good enough ways to reuse workflows or to make workflows dependent on each other.
I ended up deciding that simple is better and that publishing is a deliberate act on our part anyway (creating a Release with Github) so we can choose to release only when we know all tests pass.
Happy to get feedback on this.