This SPEC describes how to test against nightly wheels of several widely used projects and how to create nightly wheels for your project. The document use the word nightly to refer to some semi regular interval, like daily, weekly or every three days.

Regularly running your project’s tests while using the nightly version of your dependencies allows you to spot problems caused by upstream changes before a new release is made. This way potential issues can be resolved before they find their way into a release, at which point it becomes much harder to change or revert something.

Regularly creating nightly wheels for your project allows projects that depend on you to give feedback about upcoming changes. As with testing against nightlies of your dependencies this gives your dependents a chance to report problems before they find their way into a release.


This section outlines how to implement using and building nightly wheels. We assume your project already has some amount of CI infrastructure and that you will have to fit this in with the existing setup. In the notes section we link to projects who have implemented this in their setup to give you examples of complete setups.

Test with Nightly Wheels

We recommend that projects add a weekly cron job to run their tests using nightly versions of their dependencies. The cron job should automatically open an issue on your repository when it encounters an error.

If you spot a problem please investigate if this is due to a known deprecation or bug fix. If you think it is neither, please report it to the relevant upstream project.

To install the nightly version of your dependencies check which of them are available at For example to install the NumPy and scipy nightlies use:

pip install --pre --upgrade --extra-index numpy scipy

Complete examples of how projects implement this in their CI setup are linked in the Notes section.

Build Nightly Wheels

There are a few steps to implementing this for your project:

  1. Get access to, the location used to host nightly wheels
  2. Setup a CI step that builds wheels for your project
  3. Setup a CI step that uploads wheels to

For step (1) visit and create an issue requesting access. List the project you maintain and would like to upload nightlies for. Someone will reply to the issue and let you know what happens next.

The work for step (2) depends on your project. You are probably already doing this for your releases. The new thing to add is that building wheels is run on a schedule every night or once a week.

For step (3) there is a GitHub Action that you can use. You can find the action at To use it in your “build wheels workflow” add the following lines as an additional step:

- name: Upload wheel
  uses: scientific-python/upload-nightly-action@main
    artifacts_path: dist/
    anaconda_nightly_upload_token: ${{ secrets.UPLOAD_TOKEN }}

Complete examples of how projects implement this in their CI setup are linked in the Notes section.

Process for Adding New Projects

After someone creates an issue on requesting access to upload wheels a human/admin has to respond to that request.

Admins are people from the community who are ideally not part of the same organizations nor project. This is to prevent malicious activities from a given group of actors and ensure a diverse and healthy community. Adding new people to the list of admins requires at least an issue to be openned.

We want to be open to projects uploading wheels but at the same time need to perform some amount of due dilligence before giving people access. This is because once a user is given access their work will be broadcasted through the broad exposure of Scientific Python. This could be abused to publish malicious packages.

Once you have established who the person is and that they represent the project they want to upload wheels for ask the person to create an account on and tell you the username. We suggest that projects have at least 2 representatives. When considering representatives, we suggest that projects nominate individuals that do not have significant community, organizational, or employer overlap with existing representatives to ensure that we have a diverse community.

You (as an admin) can then generate a personal access token at[user]/settings/access. The token should only have the “Allow uploads to Standard Python repositories”, “Allow read access to the API site” and “Allow write access to the API site” scope. The creation of tokens at the organization level should be avoided for security reasons.

Then you need to do a first upload of a wheel to create the package listing on Once this operation is done, you can revoke your token and add the new user to its project. For a given project, at leat one user should be admin of that project.

At that point, let the user know that they have been added and that they can create a personal access token (as outlined above.) They can now upload new wheels and perform maitenance actions on their project.

Core Project Endorsement

Ecosystem Adoption