|
| 1 | +# Making a new release of nbdime |
| 2 | + |
| 3 | +The extension can be published to `PyPI` and `npm` manually or using the [Jupyter Releaser](https://github.com/jupyter-server/jupyter_releaser). |
| 4 | + |
| 5 | +## Manual release |
| 6 | + |
| 7 | +### Python package |
| 8 | + |
| 9 | +This extension can be distributed as Python packages. All of the Python |
| 10 | +packaging instructions are in the `pyproject.toml` file to wrap your extension in a |
| 11 | +Python package. Before generating a package, you first need to install some tools: |
| 12 | + |
| 13 | +```bash |
| 14 | +pip install build twine hatch |
| 15 | +``` |
| 16 | + |
| 17 | +Bump the version using the custom script: |
| 18 | + |
| 19 | +```bash |
| 20 | +python scripts/bump_version.py <new-version> |
| 21 | +``` |
| 22 | + |
| 23 | +> _\<new-version\>_ can be a segment like `major`, `minor`, `patch`, `alpha`,... |
| 24 | +
|
| 25 | +Make sure to clean up all the development files before building the package: |
| 26 | + |
| 27 | +```bash |
| 28 | +jlpm clean:all |
| 29 | +``` |
| 30 | + |
| 31 | +You could also clean up the local git repository: |
| 32 | + |
| 33 | +```bash |
| 34 | +git clean -dfX |
| 35 | +``` |
| 36 | + |
| 37 | +To create a Python source package (`.tar.gz`) and the binary package (`.whl`) in the `dist/` directory, do: |
| 38 | + |
| 39 | +```bash |
| 40 | +python -m build |
| 41 | +``` |
| 42 | + |
| 43 | +> `python setup.py sdist bdist_wheel` is deprecated and will not work for this package. |
| 44 | +
|
| 45 | +Then to upload the package to PyPI, do: |
| 46 | + |
| 47 | +```bash |
| 48 | +twine upload dist/* |
| 49 | +``` |
| 50 | + |
| 51 | +### NPM package |
| 52 | + |
| 53 | +To publish the frontend part of the extension as a NPM package, do: |
| 54 | + |
| 55 | +```bash |
| 56 | +npm login |
| 57 | +npm publish --access public |
| 58 | +``` |
| 59 | + |
| 60 | +## Automated releases with the Jupyter Releaser |
| 61 | + |
| 62 | +The extension repository should already be compatible with the Jupyter Releaser. |
| 63 | + |
| 64 | +Check out the [workflow documentation](https://jupyter-releaser.readthedocs.io/en/latest/get_started/making_release_from_repo.html) for more information. |
| 65 | + |
| 66 | +Here is a summary of the steps to cut a new release: |
| 67 | + |
| 68 | +- Add tokens to the [Github Secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets) in the repository: |
| 69 | + - `ADMIN_GITHUB_TOKEN` (with "public_repo" and "repo:status" permissions); see the [documentation](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) |
| 70 | + - `NPM_TOKEN` (with "automation" permission); see the [documentation](https://docs.npmjs.com/creating-and-viewing-access-tokens) |
| 71 | +- Set up PyPI |
| 72 | + |
| 73 | +<details><summary>Using PyPI trusted publisher (modern way)</summary> |
| 74 | + |
| 75 | +- Set up your PyPI project by [adding a trusted publisher](https://docs.pypi.org/trusted-publishers/adding-a-publisher/) |
| 76 | + - The _workflow name_ is `publish-release.yml` and the _environment_ should be left blank. |
| 77 | +- Ensure the publish release job as `permissions`: `id-token : write` (see the [documentation](https://docs.pypi.org/trusted-publishers/using-a-publisher/)) |
| 78 | + |
| 79 | +</details> |
| 80 | + |
| 81 | +<details><summary>Using PyPI token (legacy way)</summary> |
| 82 | + |
| 83 | +- If the repo generates PyPI release(s), create a scoped PyPI [token](https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/#saving-credentials-on-github). We recommend using a scoped token for security reasons. |
| 84 | + |
| 85 | +- You can store the token as `PYPI_TOKEN` in your fork's `Secrets`. |
| 86 | + |
| 87 | + - Advanced usage: if you are releasing multiple repos, you can create a secret named `PYPI_TOKEN_MAP` instead of `PYPI_TOKEN` that is formatted as follows: |
| 88 | + |
| 89 | + ```text |
| 90 | + owner1/repo1,token1 |
| 91 | + owner2/repo2,token2 |
| 92 | + ``` |
| 93 | +
|
| 94 | + If you have multiple Python packages in the same repository, you can point to them as follows: |
| 95 | +
|
| 96 | + ```text |
| 97 | + owner1/repo1/path/to/package1,token1 |
| 98 | + owner1/repo1/path/to/package2,token2 |
| 99 | + ``` |
| 100 | +
|
| 101 | +</details> |
| 102 | +
|
| 103 | +- Go to the Actions panel |
| 104 | +- Run the "Step 1: Prep Release" workflow |
| 105 | +- Check the draft changelog |
| 106 | +- Run the "Step 2: Publish Release" workflow |
| 107 | +
|
| 108 | +## Publishing to `conda-forge` |
| 109 | +
|
| 110 | +If the package is not on conda forge yet, check the documentation to learn how to add it: https://conda-forge.org/docs/maintainer/adding_pkgs.html |
| 111 | +
|
| 112 | +Otherwise a bot should pick up the new version publish to PyPI, and open a new PR on the feedstock repository automatically. |
0 commit comments