scipy-openblas32 and scipy-openblas64 have wrong permissions for their tokens

[matthewfeickert]

Also hitting this in scipy-openblas32 and scipy-openblas64, with @honno's API key, see the latest merge CI run which all failed to upload.

Originally posted by @mattip in #57 (comment)

This is a different problem than Issue #57 given the error logs

Error:  ('User "<User: _login=honno>" has not enough permissions to create "<User: _login=scientific-python-nightly-wheels>/scipy_openblas64" package', 401)
Error: Process completed with exit code 1.

so this discussion has been moved here.

[matthewfeickert]

@honno as this is your personal token (as intended 👍), can you please check that you've set permission for it correctly following #58 (comment)? If so, I would suggest regenerating the tokens and then following up with @stefanv and @jarrodmillman here to ensure permissions are being given to your individual account correctly.

[honno]

@honno as this is your personal token (as intended 👍), can you please check that you've set permission for it correctly following #58 (comment)?

Hmm couldn't figure out how I can see perms for the openblas-libs token I generated on anaconda.org 😅

I would suggest regenerating the tokens

Last time I popped the token to @mattip, so shall I do that again? Otherwise @stefanv @jarrodmillman lemme know a preferred communicatoin channel... I mean I was thinking plaintext email but I want to be sure!

This might be a good opportunity for someone closer to both OpenBLAS and sci nightly builds to be responsible for the token like @mattip?

[mattip]

Sure, I am an admin for the scipy-openblas32, scipy-openblas64, and openblas-libs packages. How can I create a token?

[tupui]

@mattip please have a look at the SPEC4 for the instructions https://scientific-python.org/specs/spec-0004/#process-for-adding-new-projects

[mattip]

I generated an API token with the three permissions specified. CI is still failing to upload scipy_openblas32-0.3.26.142-py3-none-manylinux_2_17_i686.manylinux2014_i686.whl. Note it is using the new token since it now has my username:

Error:  ('User "<User: _login=mattip>" has not enough permissions to create "<User: _login=scientific-python-nightly-wheels>/scipy_openblas32" package', 401)

When I look at https://anaconda.org/scientific-python-nightly-wheels/repo, I see these two projects are marked "collaborator".

[matthewfeickert]

@ksunden The matploltlib team seem to be uploading just fine, and are using the latest v0.3.0 action release as of matplotlib/matplotlib#27715, so can you comment on if you had to set any other permissions than what we request in https://scientific-python.org/specs/spec-0004/#process-for-adding-new-projects (which are the following (c.f. https://anaconda.org/ksunden/settings/access))?

When I look at https://anaconda.org/scientific-python-nightly-wheels/repo, I see these two projects are marked "collaborator".

@mattip I believe that just means that your mattip account has "collaborator" level permissions to the project (which is what it should be 👍).

@mattip I see that you're currently not using the uploader action. That's fine of course, but is there functionality missing in the v0.3.0 release of the action that you need that is keeping you from using it?

[mattip]

We also upload from travis, so we cannot use the action there. It seemed to make sense to be consistent.

[mattip]

Ahh, I think I see the problem. Somehow I started creating wheels with scipy_openblas64 and scipy_openblas32 rather than scipy-openblas64 and scipy-openblas32 (underline instead of dash separator). PyPI will normalize the name to use the dash, but anaconda does not.

[mattip]

I think this changed due to pypa/setuptools#4159, which now will force wheel file names for projects like scipy-openblas64 to scipy_openblas64. I will try forcing a rename of the file to restore the dash before upload.

[matthewfeickert]

@mattip it looks like you're able to upload now, so it seems that MacPython/openblas-libs#135 resolved your issue. If so, can we close this Issue now?

[mattip]

I'm not sure. Should the upload action be checking for a mismatch between the project name and the wheel name? Maybe the upload action could have an option to specify the project name?

[matthewfeickert]

I'm not sure. Should the upload action be checking for a mismatch between the project name and the wheel name? Maybe the upload action could have an option to specify the project name?

@mattip I'm confused. You confirmed that you're not using the upload action at all in #61 (comment). You're using your own workflow, and so aren't using the action that this repository provides, correct?

If so, and if the way that you're using anaconda-client's upload command isn't working as expected you should open up an Issue on https://github.com/Anaconda-Platform/anaconda-client (you will also need to be persistent though, as the repo Issues do not get lots of interaction usually).

[mattip]

OK, please close this. I hope scikit-image doesn't hit this issue.

[matthewfeickert]

I hope scikit-image doesn't hit this issue.

@mattip No worries, as everything on scikit-image is fine in the weekly scheduled workflow uploads using this action. This is a screen shot of their latest upload workflow that ran on 2024-02-04

and as can be see on https://anaconda.org/scientific-python-nightly-wheels/scikit-image/files the scikit-image wheel files are available. 👍

This action uses a lock file so there can't be any deviation in behavior in the action side software from run to run, only in the Anaconda cloud backend (as we see in Issue #57).

[mattip]

This action uses a lock file so there can't be any deviation in behavior

Cool. Thanks for closing. The problem I hit was due to the wheel building (before this action runs) so the whole thread much of my discussion is off topic. Sorry for the noise.