I am not sure if the Anaconda token that is authorised to maintainers of, say, a package X is restricted to only remove wheels for said package X, or whether it can remove all packages in the index. This is because while users of SPNW won't be affected since we handle the deletions, users with their own organisation with wheels for packages X, Y, and Z being uploaded to it would either:

• run this action somewhere centrally to remove all (but the latest N) uploads of X, Y, and Z; or
• they would want to run the deletions from separate repositories for X, Y, and Z and want to delete just X, Y, and Z at a time on each package's own accord and deletion schedule.

Which situation would be more plausible? If it is the latter, we'd have to provide another input in the action for a comma-separated string of packages to delete uploads for (and maybe * for deleting all packages?). To replace the existence of packages-ignore-from-cleanup.txt (which would exist only in this repository – see below), it might also make sense to include a whitelist input, too. If it's the former, it gets easier to implement, but users won't have fine-grained control on automations for what packages are being deleted.

P.S. This is all valid only if I'm not missing something about how the index and its permissions are structured :) Happy to receive others' thoughts!

Based on @tupui's suggestion in #95 (comment), users will need to run the action multiple times to remove old uploads for multiple packages. Hence, the second option of allowing per-package deletions is better, and an input for a list of packages to delete wheels for isn't required.

However, if someone has an appropriately scoped token for their organisation, they can very well remove multiple wheels from the index at a time, and some users might want to do that. So, it might be necessary to mention in the documentation how the tokens work and pre-emptively warn about possible deletions in an admonition.

To be clear, users have full control over their project. So they can add or remove any wheel they want on that project. People can just not add members to their project and they need to ask admins.

Please see above for context and my question on this. :)

I've put some thought into it, and this can be included as an input in the action. There would be two cases:

• An API token for package X that can delete older wheels for X
• An API token for the organisation that can perform index-wide deletions of older wheels for packages

While the former would be recommended to limit deletion scopes, when the latter is used by the action users (as it is being done here for this repo), a whitelist_packages: input can be added to include a comma-separated list of packages ("openblas-libs" in our case).

Another reasonable message could be to add a warning: "Wheels for package X requested for deletion, but X is whitelisted. Please either remove it from the whitelist or try to delete a different package as needed.".

This TODO item would also be resolved if we have a way forward with the questions above, since, if multiple packages are removed at once, this loop can stay; if we were to restrict the action to removing just one wheel at a time (which I don't think we should), then we could remove this. I think an action of the form:

- name: Remove old wheels
  uses: scientific-python/upload-nightly-action/remove-wheels@cantknowhashyet # 0.6.0
  with:
    n_latest_uploads: ${{ env.N_LATEST_UPLOADS }}
    anaconda_nightly_upload_organization: "your-organization"
    anaconda_nightly_token: ${{secrets.ANACONDA_TOKEN}}
    packages_to_remove: "mypackage1,mypackage2,mypackage3" # or just "*"
    # I could have suggested "all" here, but that breaks in the
    # case where "all" is also the name of a package that has
    # been uploaded (possible, albeit quite unlikely)

is better than specifying the step and authenticating multiple times.

packages: ["a", "b", "c"] hopefully!

Yes, a list of strings sounds elegant! :)

This is called organization, not channel; are these interchangeable terms? If so, use channel; if not, explain the difference.

I'm not quite sure, since they look like they have been used interchangeably. For example, the README outside of this PR:

mentions how one may upload to a different channel, but it uses "organization" as an input.

packages: ["a", "b", "c"] hopefully!