Skip to content

Latest commit

 

History

History
111 lines (72 loc) · 3.84 KB

RELEASE.md

File metadata and controls

111 lines (72 loc) · 3.84 KB
Raw

Making a new release of jupyterlab-niryo-one

The extension can be published to PyPI and npm manually or using the Jupyter Releaser.

Manual release

Python package

This extension can be distributed as Python packages. All of the Python packaging instructions are in the pyproject.toml file to wrap your extension in a Python package. Before generating a package, you first need to install some tools:

pip install build twine hatch

Bump the version using hatch. By default this will create a tag. See the docs on hatch-nodejs-version for details.

hatch version <new-version>

Make sure to clean up all the development files before building the package:

jlpm clean:all

You could also clean up the local git repository:

git clean -dfX

To create a Python source package (.tar.gz) and the binary package (.whl) in the dist/ directory, do:

python -m build

python setup.py sdist bdist_wheel is deprecated and will not work for this package.

Then to upload the package to PyPI, do:

twine upload dist/*

NPM package

To publish the frontend part of the extension as a NPM package, do:

npm login
npm publish --access public

Automated releases with the Jupyter Releaser

The extension repository should already be compatible with the Jupyter Releaser.

Check out the workflow documentation for more information.

Here is a summary of the steps to cut a new release:

  • Add tokens to the Github Secrets in the repository:
    • ADMIN_GITHUB_TOKEN (with "public_repo" and "repo:status" permissions); see the documentation
    • NPM_TOKEN (with "automation" permission); see the documentation
  • Set up PyPI
Using PyPI trusted publisher (modern way)
  • Set up your PyPI project by adding a trusted publisher
    • The workflow name is publish-release.yml and the environment should be left blank.
  • Ensure the publish release job as permissions: id-token : write (see the documentation)
Using PyPI token (legacy way)

  • If the repo generates PyPI release(s), create a scoped PyPI token. We recommend using a scoped token for security reasons.

  • You can store the token as PYPI_TOKEN in your fork's Secrets.

    • 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:

      owner1/repo1,token1
owner2/repo2,token2

      If you have multiple Python packages in the same repository, you can point to them as follows:

      owner1/repo1/path/to/package1,token1
owner1/repo1/path/to/package2,token2
  • Go to the Actions panel
  • Run the "Step 1: Prep Release" workflow
  • Check the draft changelog
  • Run the "Step 2: Publish Release" workflow

Publishing to conda-forge

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

Otherwise a bot should pick up the new version publish to PyPI, and open a new PR on the feedstock repository automatically.