CI: add job to build wheels and upload them when a release is tagged

[dnicolodi]

I don't know if we want this. The main goal is to potentially distribute the duty of cutting releases and reduce the bus factor. We may not want to build the wheel and the sdist for pull requests, in that case the action triggers may be changed. The current choice is only to make sure that the action works properly.

[FFY00]

While it shouldn't be a big issue for this project, I'd prefer if releases were made locally. This reduces targeting the CI as an attack vector, and allows the artifacts to be PGP signed.

[dnicolodi]

Sure, I understand. Can you please tag a 0.13.0.pre1 release as requested in #309 ?

[dnicolodi]

By the way, does PyPI support uploading GPG signed wheels?

[FFY00]

Sure, I understand. Can you please tag a 0.13.0.pre1 release as requested in #309 ?

Sure, is it worth to tag now, before #279 is in? I am in the middle of reviewing it, and was hoping to get it in early next week.
I am also working on #29, which I was hoping to merge next week.

But we definitely tag a pre-release now, and another one later.

By the way, does PyPI support uploading GPG signed wheels?

Yep, it doesn't show the signatures in the artifact list, which is fair, but you can download them. I used to also think it didn't, but it does, which is nice.

[rgommers]

Maybe just cherry-picking the gh-309 fix and doing a 0.12.1 release is the way to go there? That was a fairly annoying regression, that both scikit-image and SciPy have already burned some time on working around. That way, there's no time pressure on 0.13.0.

[FFY00]

Yeah, that makes sense. Will do.

[dnicolodi]

By the way, does PyPI support uploading GPG signed wheels?

Yep, it doesn't show the signatures in the artifact list, which is fair, but you can download them. I used to also think it didn't, but it does, which is nice.

This is nice. But how do you upload the signatures? Does twine take care of it? Does pip verify the signatures? I don't think so. Maybe I should go hunting for some documentation. This feature should maybe be advertised more.

[dnicolodi]

Sure, is it worth to tag now, before #279 is in? I am in the middle of reviewing it, and was hoping to get it in early next week.

I was under the impression that not everyone is sold on the implementation of editable wheels in #279.

I was asking for another pre-release because it seems some projects need it, but I don't know why scikit-image cannot use meson-python 0.12

[dnicolodi]

That was a fairly annoying regression, that both scikit-image and SciPy have already burned some time on working around.

Yeah. I'm sorry for the stupid regression. To my defense, that PR was reviewed in detail and no one spotted the typo.

[rgommers]

Yes, I know - such typos happen and are easy to make and to overlook in review. No worries at all there.

I was under the impression that not everyone is sold on the implementation of editable wheels in #279.

For me it's more that I don't have the time to really wrap my head around that stuff - happy to rely on you and @FFY00 here, if you both agree on the implementation and the use cases are addressed, then I think we'll be in a good place.

[FFY00]

My goal was always to shift to a better approach, like the one in #279. I think it's just a matter of if/when we are able to get it to work reliably.

[dnicolodi]

I think #279 works reliably and has extensive tests coverage. However, there may be use cases that I didn't think about and that are not covered by the tests. It would be nice if someone that uses editable wheels on complex projects tries it.

[FFY00]

But how do you upload the signatures? Does twine take care of it?

Yep, you just need to pass the --sign/-s flag to it.

Does pip verify the signatures?

No, it doesn't have the architecture to verify them in a way that actually makes sense.